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1 Introduction 

135 1.1 Overview of IHE 

Integrating the Healthcare Enterprise (IHE) is an initiative designed to stimulate the 
integration of the information systems that support modem healthcare institutions. Its 
fundamental objective is to ensure that in the care of patients all required information for 
medical decisions is both correct and available to healthcare professionals. The IHE initiative 
140 is both a process and a forum for encouraging integration efforts. It defines a technical 
framework for the implementation of established messaging standards to achieve specific 
clinical goals. It includes a rigorous testing process for the implementation of this framework, 
organizes educational sessions, exhibits at major meetings of medical professionals to 
demonstrate the benefits of this framework and encourage its adoption by industry and users. 

145 The approach employed in the IHE initiative is to support the use of existing standards, e.g 
HL7, ASTM, DICOM, ISO, IETF, OASIS, CLSI and others as appropriate, rather than to 
define new standards. IHE profiles further constrain configuration choices where necessary in 
these standards to ensure that they can be used in their respective domains in an integrated 
manner between different actors. When clarifications or extensions to existing standards are 
150 necessary, IHE refers recommendations to the relevant standards bodies. 

This initiative has numerous sponsors and supporting organizations in different medical 
specialty domains and geographical regions. In North America the primary sponsors are the 
Healthcare Information and Management Systems Society (HIMSS) and the Radiological 
155 Society of North America (RSNA) and the American College of Cardiology (ACC).IHE 
Canada has also been formed. IHE Europe (IHE-EU) is supported by a large coalition of 
organizations including the European Association of Radiology (EAR) and European 
Congress of Radiologists (ECR), the Coordination Committee of the Radiological and Electro 
medical Industries (COCIR), the Groupement pour la Modernisation du Systeme 
160 d'Information Hospitalier (GMSIH), the Societe Francaise de Radiologie (SFR), Deutsche 
Rontgengesellschaft (DRG), the Euro-PACS Association, Societa Italiana di Radiologia 
Medica (SIRM) and the European Institute for Health Records (EuroRec). In Japan IHE-J is 
sponsored by the Ministry of Economy, Trade, and Industry (METI); the Ministry of Health, 
Labor, and Welfare; and MEDIS-DC; cooperating organizations include the Japan Industries 
165 Association of Radiological Systems (JIRA), the Japan Association of Healthcare Information 
Systems Industry (JAHIS), Japan Radiological Society (JRS), Japan Society of Radiological 
Technology (JSRT), and the Japan Association of Medical Informatics (JAMI). The list 
presented here is not closed and other organizations representing healthcare professionals are 
invited to join in the expansion of the IHE process across disciplinary and geographic 
170 boundaries. 


1.2 Overview of the technical framework 

This document, the IHE PAT Technical Framework (ITI TF), defines specific 
implementations of established standards to achieve integration goals that promote 
175 appropriate sharing of medical information to support optimal patient care. It is expanded 
annually, after a period of public review, and maintained regularly through the identification 
and correction of errata. The current version, Rev. 1.14 for Trial Implementation, specifies the 
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180 


185 


190 


195 


IHE transactions defined and implemented as of January 2008. The latest version of the 
document is always available via the Internet at www.ihe.net. 

Volume 1 provides the high-level view of this framework, describes the Integration Profiles, 
defines the Actors and shows the sequencing of transactions between them. 

This document, Volume 2, provides the detailed technical description of each transaction used 
by the pathology Technical Framework: Roles of the actors, trigger events, messages 
exchanged, standards employed, triggered actions. 

These two volumes are consistent and can be used in conjunction with the Integration Profiles 
of others IHE domains. 

The other domains within the IHE initiative also produce Technical Frameworks within their 
respective areas that together form the IHE Technical Framework. Currently, the following 
IHE Technical Framework(s) are available: 

• IHE IT Infrastructure Technical Framework 

• IHE Cardiology Technical Framework 

• IHE Laboratory Technical Framework 

• IHE Pathology Technical Framework 

• IHE Patient Care Coordination Technical Framework 

• IHE Radiology Technical Framework 

Where applicable, references are made to other technical frameworks. For the conventions on 
referencing other frameworks, see Section 1.6.3 within this volume. 


200 1.3 Overview of Pathology Technical Framework Volume II 

The remainder of Section 1 further describes the general nature, purpose and function of the 
Technical Framework. Section 2 presents the conventions used in this volume to define IHE 
transactions. 

Section 3 defines transactions in detail, specifying the roles for each Actor, the standards 
205 employed, the information exchanged, and in some cases, implementation options for the 
transaction. 

The appendices following the main body of this volume provide technical details associated 
with the transactions. 

1.4 Audience 

210 The intended audience of this document is: 

• Technical staff of vendors participating in the IHE initiative 

• IT departments of healthcare institutions 

• Experts involved in standards development 

• Anyone interested in the technical aspects of integrating healthcare information systems. 
215 


1.5 Scope introduced in the current year 

The IHE Technical Framework is updated annually to reflect new profiles, corrections and 
new transactions (refer to PAT TF-2) used in those profiles. 
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220 This document refers to 2007-2008 cycle of the IHE PAT Infrastructure initiative. It will be 
the basis for the 2009 Connectathon process and exhibition process associated. 

The latest version of the document is available via the Internet at www.gmsih.fr . It has been 
produced with the help of the following organizations: 

• GMSIH (Groupement pour la Modernisation du Systeme d’lnformation Hospitalier) 

225 • ADICAP (Association pour le Developpement de l’lnformatique en Cytologie et 

Anatomie Pathologique) 

• SEIS (Spanish Health Informatics Society) 

• SEAP (Spanish Society of Pathology) 

• SFP (French Society of Pathology) 

230 • HL7 and its affiliate organizations (HL7 pathology SIG) 

• IHE organization in each participating country: IHE-France, IHE-Spain. 

• IHE-J (IHE Japan) 

1.6 Comments 

235 ADICAP, GMSIH, SEIS, SEAP, SFP welcome comments on this document and the IHE 
initiative. They should be directed to co-chairs: 

Dr Christel DANIEL Dr. Marcial Garcia Rojo 

INSERM U872 eq 20, El SESCAM 

240 15 rue de l’ecole de medecine Servicio de Salud de Castilla 

75006 - PARIS La Mancha 

Email: christel.daniel@spim.jussieu.fr Email: marcial@cim.es 

Comments may also be addressed to the IHE Pathology international mailing list: 

245 ihe-pathology @ listes .univ-rennes 1 .fr 

ihe-f-anapath@listes.univ-rennesl.fr (IHE-pathology France) 

1.7 Relationship to Standards 

The IHE Technical Framework identifies functional components of a distributed healthcare 
250 environment (referred to as IHE actors), solely from the point of view of their interactions in 
the healthcare enterprise. At its current level of development, it defines a coordinated set of 
transactions based on ASTM, DICOM, HL7, IETF, ISO, OASIS and W3C standards. As the 
scope of the IHE initiative expands, transactions based on other standards may be included as 
required. 

255 

In some cases, IHE recommends selection of specific options supported by these standards; 
however, IHE does not introduce technical choices that contradict conformance to these 
standards. If errors in or extensions to existing standards are identified, IHE’s policy is to 
report them to the appropriate standards bodies for resolution within their conformance and 
260 standards evolution strategy. 

IHE is therefore an implementation framework, not a standard. Conformance claims for 
products must still be made in direct reference to specific standards. In addition, vendors who 
have implemented IHE integration capabilities in their products may publish IHE Integration 
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265 Statements to communicate their products’ capabilities. Vendors publishing IHE Integration 
Statements accept full responsibility for their content. By comparing the IHE Integration 
Statements from different products, a user familiar with the IHE concepts of actors and 
integration profiles can determine the level of integration between them. See Appendix C for 
the format of IHE Integration Statements. 

270 

In Pathology, SNOMED is a de facto terminology standard. In Europe, Technical Committee 
CEN/TC 251 is dealing with “Health informatics” and two specific working groups have 
been recently created within DICOM and HL7. 

• DICOM WG26 

275 The group will be responsible for formulating components of the DICOM standard that relate 
to imaging for Pathology. 

Some pathology-related image formats do not as yet have applicable DICOM Information 
Object Definitions. Examples include whole-slide images (WSI), high-order multispectral 
images, flow cytometry, electron microscopy. 

280 ■ HL7 Pathology Special Interest Group 

The group will achieve a complementary effort, focusing on the "orders and observations" 
aspects of the pathology workflow 

HL7 Pathology Special Interest Group international mailing list: pathology@lists.hl7.org 

■ SNOMED Standard Board 

285 This group is integrated with internal staff from SNOMED International and external 
collaborators. They work in the definition of new terms and relationships between accepted 
terms. There is a need to define the best way to integrate SNOMED Clinical Terms in 
Pathology Information Systems (SNOMED Pathology subset), and how to exchange 
information with other clinical departments and other institutions, using a common 
290 terminology. 

• CEN TC 251 

The document TC 251 Work Item 130.( Health informatics — Service request and report 
messages), prepared under mandate M/255 given by the European Commission and the 
European Free Trade Association, has been prepared by Technical Committee CEN/TC 251 
295 “Health informatics”, and has replaced the previous standards ENV 1613 (Medical 

informatics - Messages for exchange of laboratory information)., ENV 12538 (Medical 

informatics - Referral and discharge messages), and ENV 12539 (Medical informatics - 
Request and report messages for medical service departments). The scope of the messages 
specified by this EN comprises healthcare service requests and reports related to 

300 investigations carried out by healthcare service providers on subjects of care. They cover 

electronic information exchange between computer systems used by healthcare parties 
requesting the services of, healthcare service providers. 

Typical use cases are available by CEN TC251 in prEN 14720-1:2003 (Health informatics — 
Service request and report messages — Part 1: Basic services including referral and 
305 discharge, TC 251 WI 130.1.1:2003 - E. See: http://www.centc251.org/): 

• Service to be performed on specimens supplied by the requester 


Rev 1.14 for Trial Implementation 
Publication 25/01/2008 


7/82 


Copyright © IHE-International 



IHE PAT Technical framework, vol.2 (PAT TF-2): Integration profiles 


310 


315 


• Services that require scheduling prior to the receipt of the sample collected by the 
requester (frozen sections, renal biopsy) 

• Services performed on samples collected by the service provider (fine needle 
aspiration) 

• Services in which the subject of care is examined by the service provider 

• Services involving evaluation of an existing sample or study product (second opinion) 

• Modification of an existing request following any of the above scenarios (additional 
investigations or revised clinical information) 

• Cancellation of an existing request following any of the above scenarios 

Scheduling: See section B.2.3 Services that require scheduling prior to the receipt of the 
sample collected by the requester in CEN TC-251 WI 130 Part 1 (examples: frozen section 
and renal biopsy). 


■ Harmonization 

320 It is important the five parallel efforts - IHE-pathology initiative, DICOM WG 26 and 
Pathology Special Interest Group being formed for HL7, SNOMED Standard Board, and 
CEN CT 251 - aligned, yet distinct, each with its own purpose and organizational context. 

Clearly there will be overlap in defining the information model for specimens, in 
standardizing reports including quantitative measurements and assessments made with 
325 reference to images, etc. 

Information model for specimens and templates for structured reports should be established in 
common across both standards. 

HL7-DICOM interoperation in pathology will be addressed in a HL7-DICOM joint working 
group (HL7 Pathology SIG / DICOM WG26) defining clauses for harmonization of 
330 standards. 


1.8 Relationship to Real-world Architectures 

The IHE actors and transactions described in the IHE Technical Framework are abstractions 
of the real-world healthcare information system environment. While some of the transactions 
are traditionally performed by specific product categories (e.g. HIS, Clinical Data Repository, 
335 Radiology Information Systems, Clinical Information Systems or Cardiology Information 
Systems), the IHE Technical Framework intentionally avoids associating functions or actors 
with such product categories. For each actor, the IHE Technical Framework defines only 
those functions associated with integrating information systems. The IHE definition of an 
actor should therefore not be taken as the complete definition of any product that might 
340 implement it, nor should the framework itself be taken to comprehensively describe the 
architecture of a healthcare information system. 

The reason for defining actors and transactions is to provide a basis for defining the 
interactions among functional components of the healthcare information system environment. 
In situations where a single physical product implements multiple functions, only the 
345 interfaces between the product and external functions in the environment are considered to be 
significant by the IHE initiative. Therefore, the IHE initiative takes no position as to the 
relative merits of an integrated environment based on a single, all-encompassing information 
system versus one based on multiple systems that together achieve the same end. IHE 
demonstrations emphasize the integration of multiple vendors’ systems based on the IHE 
350 Technical Framework. 
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1.9 Copyright Permission 

Health Level Seven, Inc., has granted permission to the IHE to reproduce tables from the HL7 
355 standard. The HL7 tables in this document are copyrighted by Health Level Seven, Inc. All 
rights reserved. 

Material drawn from these documents is credited where used. 

2 Conventions 

360 2.1 The Generic IHE Transaction Model 

See the "IHE Radiology Technical Framework" Volume 2, chapter 2.1. 

2.2 HL7 Profiling Conventions 

The messages used by each transaction are described in this document using static definitions 
of "HL7 constrainable message profiles". Refer to HL7 v2.5 section 2.12.6. The static 
365 definition of each message is represented within tables. At the message level, a table 
represents the message structure and its definition in terms of segments. At the segment level, 
a table details one segment and its definition in terms of fields. 

2.2.1 Static definition - message level 

Tables describing a message contains 5 columns: 

370 • Segment: gives the segment name, and places the segment within the hierarchy of the 

message, as designed by HL7: i.e. delimiting optional segments with square brackets, 
and repeatable segments with braces, and using indentation to show the hierarchy. 

• Meaning: Meaning of the segment as defined by HL7 

• Usage: Coded usage of the segment, as defined by this static definition built for the 

375 context of this particular transaction within IHE Laboratory Technical Framework. 

The coded values used in this document are: 

• R: Required: A compliant sending application shall populate all "R" elements 
with a non-empty value. A compliant receiving application shall process 
(save/print/archive/etc.) or ignore the information conveyed by required 
elements. A compliant receiving application shall not raise an error due to the 
presence of a required element, but may raise an error due to the absence of a 
required element. 

• RE: Required but may be empty. The element may be missing from the 
message, but shall be sent by the sending application if there is relevant data. A 
conformant sending application shall be capable of providing all "RE" 
elements. If the conformant sending application knows the required values for 
the element, then it shall send that element. If the conformant sending 
application does not know the required values, then that element may be 
omitted. 

390 Receiving applications will be expected to process (save/print/archive/etc.) or 

ignore data contained in the element, but shall be able to successfully process 
the message if the element is omitted (no error message should be generated if 
the element is missing). 


380 


385 
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• C: Conditional. This usage has an associated condition predicate. (See HL7 

395 v2.5 section 2.12.6.6 "Condition Predicate"). 

If the predicate is satisfied: A compliant sending application shall always send 
the element. A compliant receiving application shall process or ignore data in 
the element. It may raise an error if the element is not present. If the predicate 
is NOT satisfied: A compliant sending application shall NOT send the element. 

400 A compliant receiving application shall NOT raise an error if the condition 

predicate is false and the element is not present, though it may raise an error if 
the element IS present. 

• X: Not supported. For conformant sending applications, the element will not be 
sent. Conformant receiving applications may ignore the element if it is sent, or 

405 may raise an application error. 

• Cardinality: Within square brackets, minimum and maximum number of occurrences 
authorized for this segment, in this static definition of the message, built for the 
context of this particular transaction within IHE Laboratory Technical Framework. 

• HL7 chapter: Reference of the HL7 v2.5 chapter that describes this segment. 

410 _ Table 2-1: Initial segments of a message _ 


Segment 

Meaning 

Usage 

Card. 

HL7 chapter 

MSH 

Message Header 

R 

[1-1] 

2 

[ 

— PATIENT begin 


[1-1] 


PID 

Patient Identification 

R 

[1-1] 

3 

[ 

— PATIENT VISIT begin 


[1-1] 


PV1 

Patient Visit 

RE 

[0..1] 

3 


415 


420 


2.2.2 Static definition - segment level 

The table describing a segment and its definition in terms of fields contains 7 columns : 

• SEQ: Position (sequence) of the field within the segment. 

• LEN: Maximum length of the field 

• DT: Field Data Type 

• Usage: Usage of the field in this particular context of IHE Laboratory Technical 
Framework. Same coded values as in the message level: R, RE, C, O, X 

• Cardinality: Minimum and maximum number of occurrences for the field in this 
particular context of IHE Laboratory Technical Framework. Same meaning as in the 
message level. 

• TBL#: Table reference (for fields using a set of defined values) 

• ITEM#: HL7 unique reference for this field 

• Element Name: Name of the field. 


Table 2-2: Description of the MSH segment. 


SEQ 

LEN 

DT 

Usage 

Card. 

TBL# 

ITEM# 

Element name 

1 

1 

ST 

R 

[1-1] 


00001 

Field Separator 


Rev 1.14 for Trial Implementation 
Publication 25/01/2008 


10/82 


Copyright © IHE-International 




425 

430 

435 

440 

445 

450 

455 


IHE PAT Technical framework, vol.2 (PAT TF-2): Integration profiles 


2 

4 

ST 

R 

[1-1] 


00002 

Encoding characters 

3 

227 

HD 

R 

[1-1] 

0361 

00003 

Sending Application 










Simplification: 

For a better readability of the table, the usage “X" is not shown at the message level : if a 
segment is "not supported" by an IHE profile, it simply doesn't appear in the table 
representing the message structure. 


According to HL7 standard, if the value of a field is not present, the receiver shall not 
change corresponding data in its database. However, if the sender defines the field value 
to be the explicit NULL value (i.e. two double quotes ""), it shall cause removal of any 
values for that field in the receiver's database. This convention is fully applied by the 
Pathology Technical Lramework. 


2.3 HL7 Implementation Notes 

2.3.1 Network Guidelines 

The IHE Laboratory Technical Framework makes these recommendations: 

Applications shall use the Minimal Lower Layer Protocol defined in appendix C of the HL7 
Implementation Guide. 

An application that wants to send a message (initiate a transaction) will initiate a network 
connection to start the transaction. The receiver application will respond with an 
acknowledgement or response to query but will not initiate new transactions on this network 
connection. 

2.3.2 Message Granularity 

A message is generated from one trigger event in the real world. Therefore a message is 
related to one single order or to one order group: 

• A PAT-1 message is related to one placer order or to one placer order group. 

• A PAT-2 message is related to one filler order or to one order group. 

2.3.3 Acknowledgment Modes 

For this cycle of the IHE Pathology Technical Framework, applications that receive HL7 
messages shall send acknowledgements using the HL7 original acknowledgement mode as 
defined in HL7 v2.5 chapter 2, 2.9.2. The enhanced acknowledgement rules are not 
supported. 

2.3.4 ACK: General Acknowledgement Message 

This message is defined in HL7 chapter 2. 


Table 2-3: ACK - General Acknowledgment message description. 


Segment 

Meaning 

Usage 

Card. 

HL7 chapter 
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MSH 

Message Header 

R 

[1-1] 

2 

MSA 

Message Acknowledgement 

R 

[1-1] 

2 

[{ERR}] 

Error 

C 

[0..1] 

2 


Note: for the general acknowledgment (ACK) message, the value of MSH-9-2 trigger event is 
equal to the value of MSH-9-2 trigger event in the message being acknowledged. The value 
of MSH-9-3-Message structure for the general acknowledgment message is always ACK. The 
Condition Predicate for using an ERR segment is specified in the transaction chapters. 

2.3.5 Identifier Data Types 

This section describes the IHE constraints of the data types. 


2.3.5.1 El Data Type 

The constraints below particularly apply to the following fields: placer group number, placer 
order number, filler order number and specimen number. 


Table 2-4: El Data Type. 


SEQ 

LEN 

DT 

Usage 

CARD 

TBL# 

COMPONENT NAME 

1 

16 

ST 

R 

[1..1] 


Entity Identifier 

2 

20 

IS 

c 

[0-1] 

0363 

Namespace ID 

3 

199 

ST 

c 

[0..1] 


Universal ID 

4 

6 

ID 

c 

[0..1] 

0301 

Universal ID Type 


Component 1 is required. Either component 2 or both components 3 and 4 are required. 
Components 2, 3 and 4 may be all present. 

The El is appropriate for machine or software generated identifiers. The generated identifier 
goes in the first component. The remaining components, 2 through 4, are known as the 
assigning authority; they can also identify the machine/system responsible for generating the 
identifier in component 1. 

Example 1: AB12345 A RiversideHospital 

Example 2: AB12345 AA 1.2.840.45.67 A ISO 

Example 3: AB12345 A RiversideHospital A l.2.840.45.67 A ISO 

IHE restrains the length of the first component to 16 characters. National extensions can 
extend this length up to a maximum of 199. 

IHE recommands to fill component 2 “Namespace ID” in all cases. Particularly when there 
are several concurrent assigning authorities within the healthcare enterprise, this Namespace 
ID will indicate which assigning authority provided this number. 


This happens for instance, when there are several Order Placer actors within the enterprise, 
each one assigning placer order numbers and placer group numbers. 


Example 4: Placer order number 9876543 and placer group number 777 assigned by the 
Order Placer actor operated by the department of surgery A. 


ORC | NW | 987 65 43 A SurgA | | 77 7 A SurgA|| . . . 


Example 5: Placer order number 9876543 and placer group number 555 assigned by the 
Order Placer actor operated by the department of surgery B. 


ORC|SC|987 6543 A SurgB| |555 A SurgB | 
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This also commonly happens when there are several Order Filler actors within the enterprise, 
each one assigning its own filler order numbers and specimen numbers. 

Example 6: Filler order number and specimen number assigned by the Order Filler actor 
operated by the clinical laboratory of pathology. 

SPM|1|45611 A Pathology|... 


OBR|1|456 A Pathology|... 


23 . 5.2 CX Data Type 


The constraints below particularly apply to the Patient Identifiers (PID segment). 


Table 2-5: CX Data Type 


SEQ 

LEN 

DT 

Usage 

CARD 

TBL# 

COMPONENT NAME 

1 

15 

ST 

R 

[1-1] 


ID Number 

2 

1 

ST 

O 

[0..1] 


Check Digit 

1 3 

3 

ID 

O 

[0..1] 

0061 

Check Digit Scheme 

4 

227 

HD 

R 

[1-1] 

0363 

Assigning Authority j 

i 5 

5 

ID 

RE 

[0..1] 

0203 

Identifier Type Code 

1 6 

227 

HD 

O 

[0..1] 


Assigning Facility 

7 

8 

DT 

O 

[0..1] 


Effective Date 

1 8 

8 

DT 

O 

[0..1] 


Expiration Date 

1 9 

705 

CWE 

O 

[0..1] 


Assigning Jurisdiction 

10 

705 

CWE 

O 

[0..1] 


Assigning Agency or 
Department 


The data type has been constrained because the Assigning Authority and the Identifier Type 
Code as essential components. The most common value for the Identifier Type Code in PID-3 
is “PI”. Other values are defined in Table 0203 of HL7 2.5 section 2.A.14.5. 


Example: 12345 AAA Saint-John Hospital A PI 


2.4 DICOM Usage Conventions 

For some DICOM transactions described in this document, IHE has strengthened the 
requirements on the use of selected Type 2 and Type 3 attributes. These situations are 
explicitly documented in section 4 and in the appendices. 

IHE specifically emphasizes that DICOM Type 2 attributes (for instance, Patient Name, 
Patient ID) shall be transmitted with zero length if the source system does not possess valid 
values for such attributes; in other words, the source system shall not assign default values to 
such attributes. The receiving system must be able to handle zero-length values for such 
attributes. 

IHE has also defined requirements related to the support for and use of matching and return 
keys in DICOM queries by both Service Class Users (SCUs) and Service Class Providers 
(SCPs). Matching keys are used to select instances for inclusion in the response by the query 
SCP to the SCU, whereas return keys only return specific data and are not used for matching. 

• Required matching key SCU : 

A key that the Query SCU shall have the ability to offer to its user as a selection 
criterion. The definition of the means offered to the user of the Query SCU to 
trigger the sending of a matching key in the Query request is beyond the scope of 
IHE (e.g. enter a value, select an entry). 

• Required matching key SCP: 
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An IHE required matching key is processed by the Query SCP just as if it were a 
525 DICOM-required matching key. In most cases, IHE-required matching keys are 

also DICOM-required matching keys. 

• Required return key SCU : 

A key that the Query SCU requests from the Query SCP, receives in the query 
responses, and displays for the user, if required. The definition of the means 
530 offered to the user of the Query SCU to request a return key (e.g. by default, check 

a box) and to make it visible to the user is beyond the scope of IHE. 

• Required return key SCP: 

IHE-required return keys specified within DICOM as type 1 or type 2 return keys 
are processed according to their DICOM type. IHE-required return keys specified 
535 within DICOM as type 3 will be processed as if they were type 2. 

Query Key Requirement Tables in the framework use the following legend to specify 
requirements for SCUs and SCPs: 

R Required 

O Optional 

540 The following modifiers are also used: 

R+ The Requirement is an IHE extension of the DICOM requirements 
R* The attribute is not required to be displayed 

R+* The Requirement is an IHE extension of the DICOM requirements, but it is 
NOT required to be displayed 

545 Table 2-6 provides an example table defining matching and return keys. Note that sequence 
attributes are used as a structuring header in these matching and return key tables, and 
requirements are given for individual sequence items. 


Table 2-6: Images Query Matching and Return Keys. 


Attributes Name 

Tag 

Query Keys 
Matching 

Query Keys 
Return 

Notes 

SCU 

SCP 

SCU 

SCP 

Scheduled Human 
Performers Sequence 

(0040,4034) 






>Human Performer 

Code Sequence 

(0040,4009) 






»Code Value 

(0008,0100) 

R+ 

R 

R+* 

R 


»Coding Scheme 
Designator 

(0008,0102) 

R+ 

R 

R+* 

R 


»Code Meaning 

(0008,0104) 



R+ 

R 

Query Keys Matching 
SCU or SCP do not 
use the Code Meaning 
values (“-“). 

>Human Performer's 
Name 

(0040,4037) 

R+ 

R+ 

R+ 

R+ 


>Human Performer's 
Organization 

(0040,4036) 

O 

O 

O 

R+ 























Input Information 

(0040,4021) 
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Sequence 







>Study Instance UID 

(0020.000D) 

0 

O 

R+* 

R 
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550 

OPEN ISSUES 

Volume 2: 

1. Examples of transactions corresponding to use cases will be further provided. 

555 2. Vocabulary tables for HL7 SPM-Specimen segment (SPM-4 Specimen Type (table 

0487), SPM-8 Specimen Source Site, etc) and DICOM Specimen Module ((Coded 
Specimen Type (context ID ccc5), Specimen (“general”) type (context ID ccc3), 
“general” specimen collection procedure (context ID cclO)) should be aligned 
(defined with SNOMED and/or LOINC codes? 

3. Instance availability notification 

Add a new transaction from the Image Imager to the Order Filler to notify that a 
DICOM instance has been stored. It may enable the Order Filler to include such 
information in the transaction to the Order Result Tracker. Additionally it may be used 
by the Order Filler to update the Worklist contents for the Modality which produced 
the instance for the particular specimen, considering the modality no longer needs this 
entry in the worklist. 

3 Common Message Segments 

This section describes the common message segments used by the transactions PAT-1, PAT- 
570 2, PAT-3 and PAT-4. 

Each table represents a segment. The fields for which IHE Pathology Technical Framework 
brings some precision of usage are commented only. The optional fields are not shown in the 
tables, unless they require a particular comment within the context of the IHE Framework. 

3.1 MSH - Message Header segment 

575 HL7 v2.5: chapter 2 (2.15 Message control) 

This segment defines the intent, source, destination, and some specifics of the syntax of a 
message. 

___ Table 3-1: MSH - Message Header segment. _ 

SEQ LEN DT Usage Card. TBL# ITEM# Element name 

1 1 SI R [1..1] 00001 Field Separator 

2 4 ST R [1..1] 00002 Encoding Characters 

3 227 HD R [1..1] 00003 Sending Application 

4 227 HD R [1..1] 00004 Sending Facility 

5 227 HD R [1..1] 00005 Receiving Application 

6 227 HD R [1..1] 00006 Receiving Facility 

7 26 TS R [1..1] 00007 Date/Time of Message 

8 40 ST X [0..0] 00008 Security 

9 15 MSG R [1..1] 00009 Message Type 

10 20 ST R [1..1] 00010 Message Control Id 


560 


565 
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11 

3 

PT 

R 

[1-1] 


00011 

Processing Id 

12 

60 

VID 

R 

[1-1] 


00012 

Version ID 

14 

180 

ST 

X 

[0..0] 


00014 

Continuation Pointer 

15 

2 

ID 

X 

[0..0] 

0155 

00015 

Accept Acknowledgement Type 

16 

2 

ID 

X 

[0..0] 

0155 

00016 

Application Acknowledgement Type 

17 

3 

ID 

RE 

[1-1] 

0399 

00017 

Country Code 

18 

16 

ID 

C 

[0..1] 

0211 

00692 

Character Set 

19 

250 

CE 

RE 

[1-1] 


00693 

Principal Language of Message 

21 

427 

El 

RE 

[0..*] 


01598 

Message Profile Identifier 


MSH-1 Field Separator, required: The IHE Pathology Technical Framework requires that 
580 applications support HL7-recommended value that is I (ASCII 124). 

MSH-2 Encoding Characters, required: This field contains the four characters in the 
following order: the component separator, repetition separator, escape character, and 
subcomponent separator. The IHE Pathology Technical Framework requires that applications 
support HL7-recommended values A ~\& (ASCII 94, 126, 92, and 38, respectively). 

585 MSH-4 Sending Facility (HD), required: 

Components: <Namespace ID (IS)> A <Universal ID (ST)> A <Universal ID Type (ID)> 

The IHE Pathology Technical Framework requires that this field be populated with: 

First component (required): Namespace ID, the name of the organizational entity responsible 
for the sending application. 

590 Second component (optional): The URI (OID) of the organizational entity responsible for the 
sending application. 

Third component (optional): The type of identification URI provided in the second 
component of this field. The codification of these three components is entirely site-defined. It 
may be detailed in the national extensions of this framework. 

595 MSH-6 Receiving Facility (HD), required: 

Components: <Namespace ID (IS)> A cUniversal ID (ST)> A cUniversal ID Type (ID)> 

The IHE Pathology Technical Framework requires that this field be populated with: 

First component (required): Namespace ID, the name of the organizational entity responsible 
for the receiving application. 

600 Second component (optional): The URI (e.g. OID) of the organizational entity responsible for 
the receiving application. 

Third component (optional): The type of identification URI provided in the second 
component of this field. The codification of these three components is entirely site-defined. It 
may be detailed in the national extensions of this framework. 

605 MSH-9 Message Type (MSG), required: 

Components: <Message Code (ID)> A <Trigger Event (ID)> A <Message Structure (ID)> 

Definition: This field contains the message type, trigger event, and the message structure ID 
for the message. All three components are required. 
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Its content is defined within each transaction-specific section of this document. 

610 MSH-10 Message Control Id (ST), required: 

Definition: This field contains a number or other identifier that uniquely identifies the 
message. Each message should be given a unique identifier by the sending system. The 
receiving system will echo this ID back to the sending system in the Message 
Acknowledgment segment (MSA). The combination of this identifier and the name of the 
615 sending application (MSH-3) should be unique across the Healthcare Enterprise. 

MSH-12 Version ID (VID), required: 

Components: cVersion ID (ID)> A <Internationalisation Code (CE)> A international Version 
ID (CE)> 

Definition: This field is matched by the receiving system to its own version to be sure the 
620 message will be interpreted correctly. 

The IHE Pathology Technical framework requires the first component to be populated with 
the value "2.5" representing HL7 release 2.5. 

MSH-17 Country Code (ID), required if available. 

Definition: This field contains the country of origin for the message. The values to be used 
625 are those of ISO 3166, with the 3-character (alphabetic form). Refer to HL7 2.5 Table 0399 - 
Country code chapter 2.15.9.17. 

Examples of valid values: 

JPN = Japan, USA = United States, GBR = United Kingdom, ITA = Italy, FRA = France, 
NLD = Netherlands. 

630 MSH-18 Character Set (ID), conditional. 

Definition: This field contains the character set for the entire message. Refer to HL7 table 
0211 - Alternate character sets for valid values. 

Examples of valid values: 

ASCII: The printable 7-bit ASCII character set. 

635 8859/1: The printable characters from the ISO 8859/1 Character set used by Western Europe. 

This character set can still be used, but 8859/15 should be used by preference. This character 
set is the forward-compatible version of 8859/1 and includes new characters such as the Euro 
currency symbol. 

ISO IR87: Code for the Japanese Graphic Character set for information interchange (JIS X 
640 0208-1990). 

UNICODE UTF-8: UCS Transformation Format, 8-bit form. 

Condition predicate: This field shall only be valued if the message uses a character set other 
than the 7-bit ASCII character set. Though the field is repeatable in HL7, IHE authorizes only 
one occurrence (i.e. one character set). The character set specified in this field is used for the 
645 encoding of all of the characters within the message. 

MSH-19 Principal Language of Message (CE), required if available. Coded from ISO 639. 

Examples: DE = German, EN = English, ES=Spanish, JA = Japanese, FR = French, NL = 
Dutch, IT = Italian 

MSH-21 Message Profile Identifier (El), required if available. 
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650 For IHE Pathology Technical Framework, this field shall only be valued in the messages for 
which a Message Profile has been officially defined and identified. When multiple message 
profiles are listed in this field, they should be (vendor specific, country specific) constraints of 
the IHE Pathology Profile. Note that the overriding of IHE Pathology Profile constraints is 
only allowed in national extensions to this framework. 

655 3.2 MSA - Message Acknowledgement segment 

HL7 v2.5: chapter 2 (2.15 Message control) 

This segment contains information sent while acknowledging another message. 


Table 3-2: MSA - Message Acknowledgement segment. 


SEQ 

LEN 

DT 

Usage 

Card. 

TBL# 

ITEM# 

Element name 

1 

2 

ID 

R 

[1-1] 

0008 

00018 

Acknowledgement code 

2 

20 

ST 

R 

[1-1] 


00010 

Message Control Id 

5 



X 

[0..0] 


00022 

Delayed Acknowledgment Type 

6 

250 

CE 

X 

[0..0] 

0357 

00023 

Error Condition 


660 MSA-1 Acknowledgment Code (ID), required. 

The IHE Pathology Technical Framework authorizes only one of the three values below, 
taken from HL7 table 0008 - Acknowledgement code : 


Table 3-3: Acknowledgement codes (HL7 table 0008). 


Value 

Description 

Comment 

AA 

Original mode: Application 
Accept 

The message has been accepted and integrated by the 
receiving application 

AE 

Original mode: Application 
Error 

The sender should try again to send the message later 

AR 

Original mode: Application 
Reject 

The message has been rejected by the receiving 
application 


MSA-2 Message Control ID (ST), required. 


665 Definition: This field contains the message control ID from the MSH-10 - Message Control 
ID of the incoming message for which the acknowledgement is sent. 

3.3 ERR - Error segment 

HL7 v2.5: chapter 2 (2.15 Message control) 

This segment is used to add error comments to acknowledgment messages. 

670 ___ Table 3-4: ERR - Error segment. _ 


SEQ 

LEN 

DT 

Usage 

Card. 

TBL# 

ITEM# 

Element name 

1 

493 

ELD 

X 

[0..0] 


00024 

Error Code and Location 

3 

705 

CWE 

R 

[1-1] 

0357 

01813 

HL7 Error Code 

4 

2 

ID 

R 

[1-1] 

0516 

01814 

Severity 


Note: ERR-1 is included in HL7 v2.5 for backM’ard compatibility only. Within the context of 
Pathology, this field shall not be used. ERR-3 and ERR-4 are required by HL7 v2.5 
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3.4 NTE - Notes and Comment segment 

HL7 v2.5: chapter 2 (2.15 Message control) 

675 This segment is used for sending notes and comments. 

The IHE Pathology Technical Framework limits the use of this segment to only one purpose: 
to comment the observations and the orders. Therefore, in the messages of this Integration 
Profile, NTE segments appear only below OBR or OBX segments. 

Information that can be coded in OBX segments or OBR segments shall not be sent in a NTE 
680 segment. 


Table 3-5: NTE - Notes and Comment segment. 


SEQ 

LEN 

DT 

Usage 

Card. 

TBL# 

ITEM# 

Element name 

1 

4 

SI 

R 

[1-1] 


00096 

Set ID - NTE 

2 

8 

ID 

RE 

[0..1] 


00097 

Source of Comment 

3 

65536 

FT 

RE 

[0..1] 


00098 

Comment 

4 

250 

CE 

RE 

[0..1] 


01318 

Comment Type 


NTE-1 Set ID - NTE (SI), required. 

NTE-2 Source of Comment (ID), required but may be empty. 

IHE Pathology Technical Framework populates this field with one of these values: 

685 Table 3-6: Source of Comment. 


Value 

Meaning 

Comment 

L 

Order Filler is the source of the comment 


P 

Order Placer is the source of the comment 


O 

Other System is the source of the comment 



NTE-3 Comment (FT), required but may be empty: This field contains the text of the 
comment. This text may be formatted. In order to delete an existing comment, the field shall 
contain empty quotation marks: " ". 

Comment text of identical type and source shall be included in the same occurrence of an 
690 NTE segment, and not be split over multiple segments. 

NTE-4 Comment Type (CE), required if known. 

The IHE Pathology Technical Framework populates this field with one of these values: 


Table 3-7: Comment Type. 


Value 

Meaning 

Comment 

I 

Internal remark, that shall not be sent outside of 
the Pathology 

Shall not be sent to the Order 

Result Tracker 



3.5 PID - Patient Identification segment 

695 HL7 v2.5: chapter 3 (3.4.2) 

The PID segment is used by all applications as the primary means of communicating patient 
identification information. This segment contains permanent patient identifying and 
demographic information that, for the most part, is not likely to change frequently. 
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1 

fable 3-8: PID - Patienl 

t Identification segment. 

SEQ 

LEN 

DT 

Usage 

Card. 

TBL# 

ITEM# 

Element name 

1 

4 

SI 

0 

[1-1] 


00104 

Set ID - PID 

2 

20 

CX 

X 

[0..1] 


00105 

Patient ID 

3 

250 

CX 

R 

[1..*] 


00106 

Patient Identifier List 

4 

20 

CX 

X 

[0..1] 


00107 

Alternate Patient ID - PID 

5 

250 

XPN 

R 

[1..*] 


00108 

Patient Name 

6 

250 

XPN 

0 

[0..1] 


00109 

Mother’s Maiden Name 

7 

26 

TS 

RE 

[0..1] 


00110 

Date/Time of Birth 

8 

1 

IS 

R 

[1-1] 

0001 

00111 

Administrative Sex 

9 

250 

XPN 

X 

[0..1] 


00112 

Patient Alias 

10 

250 

CE 

0 

[0..1] 

0005 

00113 

Race 

11 

250 

XAD 

RE 

[0..*] 


00114 

Patient Address 

12 

4 

IS 

X 

[0..1] 

0289 

00115 

County Code 

13 

250 

XTN 

0 

[0..*] 


00116 

Phone Number - Home 

14 

250 

XTN 

0 

[0..*] 


00117 

Phone Number - Business 

15 

250 

CE 

0 

[0..1] 

0296 

00118 

Primary Language 

16 

250 

CE 

0 

[0..1] 

0002 

00119 

Marital Status 

17 

250 

CE 

0 

[0..1] 

0006 

00120 

Religion 

18 

250 

CX 

0 

[0..1] 


00121 

Patient Account Number 

19 

16 

ST 

X 

[0..1] 


00122 

SSN Number - Patient 

20 

25 

DLN 

X 

[0..1] 


00123 

Driver's License Number - 
Patient 

21 

250 

CX 

0 

[0..*] 


00124 

Mother's Identifier 

22 

250 

CE 

0 

[0..1] 

0189 

00125 

Ethnic Group 

23 

250 

ST 

0 

[0..1] 


00126 

Birth Place 

24 

1 

ID 

0 

[0..1] 

0136 

00127 

Multiple Birth Indicator 

25 

2 

NM 

0 

[0..1] 


00128 

Birth Order 

26 

250 

CE 

0 

[0..1] 

0171 

00129 

Citizenship 

27 

250 

CE 

0 

[0..1] 

0172 

00130 

Veterans Military Status 

28 

250 

CE 

X 

[0..0] 

0212 

00739 

Nationality 

29 

26 

TS 

0 

[0..1] 


00740 

Patient Death Date and 

Time 

30 

1 

ID 

0 

[0..1] 

0136 

00741 

Patient Death Indicator 

31 

1 

ID 

RE 

[0..1] 

0136 

01535 

Identity Unknown 

Indicator 

32 

20 

IS 

RE 

[0..1] 

0445 

01536 

Identity Reliability Code 

35 

250 

CE 

C 

[0..1] 

0446 

01539 

Species Code 

36 

250 

CE 

C 

[0..1] 

0447 

01540 

Breed Code 
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700 The specific usage of these fields, especially those fields with usage "O" (optional) in the 
table above, is explained in the national extensions. 

PID-7, Date/Time of Birth (TS). If the exact date of birth is not known, the second 
component of this field can be used to describe the degree of precision of the information 
entered in the first component. 

705 PID-10, Race (CE). This field may be further constrained in national extensions of this PAM 

profile. For instance, it will be required if available (usage code RE) in the US extension, but 
will not be supported (usage code X) in the French extension. 

PID-18, Patient Account Number (CX). 

HL7 Definition: this field contains the patient account number assigned by accounting to 
710 which all charges, payments, etc., are recorded. It is used to identify the patient’s account. 

Relationship to encounter: A patient account can span more than one enterprise encounter. At 
least one of the fields PID-18 “Patient Account Number” or PV1-19 “Visit Number” shall be 
valued in the messages of transaction ITI-31 that use the PV1 segment. Additional 
requirements for the presence of value in these fields may be documented in national 
715 extensions of this profile. 

PID-35, Species Code (CE). 

Condition predicate: shall be used if the test subject is a non-human living subject. 

PID-36, Breed Code (CE). 

Condition predicate: shall be used if the test subject is a non-human living subject. 

720 3.6 PV1 - Patient Visit segment 

HL7 v2.5: chapter 3 (3.4.3) 

The PV1 segment is used by Registration/Patient Administration applications to communicate 
information on an account or visit-specific basis. 


Table 3-9: PV1 - Patient Visit segment. 


SEQ 

LEN 

DT 

Usage 

Card. 

TBL# 

ITEM# 

Element name 

2 

1 

IS 

R 

[1-1] 

0004 

00132 

Patient Class 

3 

80 

PL 

RE 

[0..1] 


00133 

Assigned Patient 

Location 

9 

250 

XCN 

X 

[0..0] 

0010 

00139 

Consulting Doctor 

19 

250 

CX 

O 

[0..1] 


00149 

Visit Number 

40 

1 

IS 

X 

[0..0] 

0116 

00170 

Bed Status 

51 

1 

IS 

C 

[0..1] 

0326 

01226 

Visit Indicator 

52 

250 

XCN 

X 

[0..0] 

0010 

01274 

Other Healthcare 

Provider 


725 The specific usage of these fields may be elaborated upon in the national extensions. 

PV1-19, Visit Number (CX). This field contains the unique identifier assigned to the 
encounter. At least one of the fields PID-18 “Patient Account Number” or PV1-19 “Visit 
Number” shall be valued in the messages of transaction ITI-31 that use the PV1 segment. 
Additional requirements for the presence of values in these fields may be documented in 
730 national extensions of this profile. 
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PV1-51, Visit Indicator (IS). Shall be valued with value 'V' if the field PV1-19 is present. 
The field may be omitted otherwise. 

The PV1 segment doesn’t entirely cover the data model as defined in this framework. In some 
countries (especially in Europe), national extensions will define new segment to manage 
735 issues like ‘functional units’. 

The use of the PV1 segment shall be clarified in each national extension. 

3.7 ORC Common Order segment 

HL7 v2.5: chapter 4 (4.5.1). The ORC and OBR segments contain a number of duplicate 
fields. The Pathology Technical Framework is defined is such a way that fields in the OBR 
740 segment will be used in prevalence over their equivalents in ORC. If a field is listed as being 
optional in ORC, its equivalent in OBR may well be mandatory. 


Table 3-10: C 

IRC - Common C 

irder segment. 

SEQ 

LEN 

DT 

Usage 

Card. 

TBL# 

ITEM# 

Element name 

1 

2 

ID 

R 

[1-1] 

0119 

00215 

Order Control 

2 

22 

El 

C 

[0..1] 


00216 

Placer Order Number 

3 

22 

El 

C 

[0..1] 


00217 

Filler Order Number 

4 

22 

El 

RE 

[0..1] 


00218 

Placer Group Number 

5 

2 

ID 

C 

[0..1] 

0038 

00219 

Order Status 

7 

200 

TQ 

X 

[0..0] 


00221 

Quantity/T iming 

8 

200 

EIP 

X 

[0..0] 


00222 

Parent 

9 

26 

TS 

R 

[1-1] 


00223 

Date/Time of Transaction 

10 

250 

XCN 

RE 

[0..*] 


00224 

Entered By 

11 

250 

XCN 

RE 

[0..*] 


00225 

Verified By 

12 

250 

XCN 

RE 

[0..*] 


00226 

Ordering Provider 

14 

250 

XCN 

RE 

[0..*] 


00228 

Call Back Phone Number 

16 

250 

CE 

RE 



00230 

Order Control Code Reason 

17 

250 

CE 

RE 

[0..1] 


00231 

Entering Organization 

18 

250 

CE 

X 



00232 

Entering Device 

19 

250 

XCN 

X 

Y 


00233 

Action By 

20 

250 

CE 

X 

[0..0] 

0339 

01310 

Advanced Beneficiary Notice Code 

21 

250 

XON 

RE 

[0..1] 


01311 

Ordering Facility Name 

25 

250 

CWE 

X 

[0..0] 


01473 

Order Status Modifier 

26 

60 

CWE 

X 

[0..0] 

0552 

01641 

Advanced Beneficiary Notice 

Override Reason 

27 

26 

TS 

C 

[0..1] 


01642 

Filler's Expected Availability 
Date/Time 

30 

250 

CNE 

X 


0483 

01644 

Enterer Authorization Mode 


ORC-1 Order Control (ID), required. This field may be considered the "trigger event" 
identifier for orders. Many order control codes are defined in the HL7 table 0119 - Order 
745 Control Codes. The IHE Pathology Technical Framework allows only the following subset: 
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Table 3-11: Supported Order Control codes. 


Value 

Description of use 

NW 

“New Order”. Event request in OML message sent by the Order Placer in transaction 
PAT-1. 

OK 

“Notification or request accepted”. Event notification in OML message. Event 
acknowledgement in ORL message. 

UA 

“Unable to accept order/service”. Event notification in OML message. Event 
acknowledgement in ORL message sent by the Order Filler in transaction PAT-1. 

SC 

“Status changed”. Event notification in OML. 

XO 

“Change order/service request”. Event request in OML message sent by the Order 
Filler in PAT-4. 

CA 

“Cancel order/ service request”. Event request in OML message sent by the Order 
Placer in PAT-1. 

CR 

“Canceled as requested”. Event acknowledgement in ORL message responding to 

OML (CA). 

UC 

“Unable to cancel”. Event acknowledgement in ORL message responding to OML 
(CA). 

OC 

“Order service canceled”. Event notification in OML message sent by the Order Filler 
in transaction PAT-1 and in ORU message sent by the Order Result Tracker in 
transaction PAT-3. 

SN 

“Send order/service number”. Event request in OML message sent by the Order Filler 
in transaction PAT-2 

NA 

“Number assigned”. Event acknowledgement in ORL message sent by the Order 

Placer in PAT-2, responding to OML (SN) 


ORC-2 Placer Order Number (El), conditional. 

Condition predicate: This field shall be valued in all OML/ORL messages sent by the Order 
750 Placer. 

If the field is valued then its value shall match the value of the required field OBR-2. Please 
refer to section 2.3.5.1 for the details of the data type. 

ORC-3 Filler Order Number (El), conditional. 

Condition predicate: This field shall be valued in all OML/ORL messages sent by the Order 
755 Filler and in all ORL messages sent by the Order Placer 

If the field is valued then its value shall match the value of the required field OBR-3. Please 
refer to section 2.3.5.1 for the details of the data type. 

ORC-4 Placer Group Number (El), required if known to the sender. 

The Placer Group Number represents an identification of a set of closely related orders, i.e. 
760 the whole list of specimen ordered by the placer to the Pathology for one subject. Please refer 
to section 2.3.5.1 for the details of the data type. 

ORC-5 Order Status (ID), conditional. 
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Condition predicate: This field shall be valued in all OML messages sent by the Order Filler. 
It represents the status of the order. This field shall not be valued in OML messages sent by 
765 the Order Placer. 

The allowed values for this field within IHE Pathology Technical Framework are a subset of 
HL7 table 0038 - Order Status: 

Table 3-12: IHE subset of Order Status for all transactions. 


Value 

Description 

Comment 

A 

Some, but not all, results available 


CA 

Order was canceled 


CM 

Order is completed 


IP 

In process, unspecified 


DC 

Order was discontinued 


RP 

Order has been replaced 



ORC-9 Date/Time of Transaction (TS), required 

770 HL7 Definition: This field contains the date and time of the event that initiated the current 
transaction as reflected in ORC-1 Order Control Code. This field is not equivalent to MSH-7 
Date and Time of Message that reflects the date/time of the creation of the physical message. 

In OML messages "Status changed" sent by the Order Filler, this field contains the date/time 
of the last status change of the order (ORC-5) or one of the requested procedure (identified in 
775 the following OBR). 

ORC-10 Entered By (XCN), optional. This field contains the identity of the person who 
actually keyed the request into the application. 

ORC-11 Verified By (XCN), optional. This field contains the identity of the person who 
verified the accuracy of the entered request. 

780 Difference with ORC 10 Entered By and ORC 11 Verified By: 

Field ORC 10 identifies the person who enters the information in the information system, and 
ORC11 identify the person who verify the accuracy of the information entered if the enterer is 
a technician, for example. 

ORC-12 Ordering Provider (XCN), optional. If the field is valued then its value has to 
785 match the value of the required field OBR-16. 

This field contains the person (physician) who prescribed this order. See the data model in 
volume 1. 

ORC-14 Callback Phone Number (XTN), optional. If the field is valued then its value has 
to match the value of the required field OBR-17. 

790 ORC-17 Entering Organization (CE) identify the organization that enterer (ORC 10) 
belongs to when the information is entered to the information system. 

ORC-21 Ordering Facility Name (XON), required but may be empty. 

This field contains the facility (care unit) placing this order. These three components shall be 
valued: 1st = Organization name. 7th = Identifier Type Code with the value “FI”, which 
795 means “Facility ID” as stated by HL7 table n° 0203. 10th = Organization Identifier. Example: 
SurgA AAAAAA FI AAA UR01. 
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The fields ORC-17 and ORC-21 will be specified in the national extensions. 

ORC-27 Fillers Expectable Availability Date/Time (TS), conditional. 

This field contains the date/time when the Pathology results are expected to be available. 

800 Condition predicate: This field may be valued only in OML messages sent by the Order Filler 

3.8 TQ1 - Timing Quantity segment 

HL7 v2.5: chapter 4 (4.5.4) 


Table 3-1 

13: TQ1 

- Timing Quantity segment. 

SEQ 

LEN 

DT 

Usage 

Card. 

TBL# 

ITEM# 

Element name 

9 

250 

CWE 

R 

[1-1] 

0485 

01635 

Priority 

12 

10 

ID 

C 

[0..1] 

0427 

01638 

Conjunction 


This cycle of IHE Pathology Technical Framework does not use TQ2 segment, and uses only 
805 one occurrence of TQ1 segment, with a single field required in it: TQ1-9 Priority (CWE). 
This field defines the priority of the order. The authorized values for this field are listed in 
HL7 table 0485 - Priority codes. Only 3 priority codes are allowed by IHE Pathology: 


Table 3-14: Priority codes. 


Value 

Description 

Comment 

S 

Stat 

With highest priority for extemporaneous orders 

A 

ASAP 

As soon as possible. Fulfills after S orders. 

R 

Routine 

Default 


All the other fields of TQ1 segment are left optional in this release of the framework. 

810 TQ1-12 Conjunction (ID), conditional. 

Condition predicate: this field shall only be used when the TQ1 segment occurs several times. 
In this Framework, TQ1 segment may occur only once. Therefore, this field shall never be 
filled. 

3.9 SPM - Specimen Segment 

815 HL7 v2.5: chapter 7 (7.4.3). 

For specimen definition, specimen types, relationship between specimen and container and 
examples of specimen identification, see Pathology TF-1, Appendix B, section 5.2. 

The Specimen segment (SPM) is used in PAT-1, PAT-2, PAT-3 and PAT-4. In PAT-1, PAT- 
2 and PAT-3, the specimen is a part (uniquely identified tissue or material collected from the 
820 patient and delivered to the pathology department for examination). In PAT-4, the specimen 
can be a physical object (or a collection of objects) the laboratory considers it a single 
discrete, uniquely identified unit that is the subject of one or more steps in the laboratory 
(diagnostic) workflow (tissue item, tissue section, tissue core, tissue spot, smear sample, 
touch preparation, dispersion, etc). 

825 
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Table 3-15: SPM - Specimen segment. 


SEQ 

LEN 

DT 

Usage 

Card. 

TBL# 

ITEM# 

Element name 

2 

80 

EIP 

C 

[0..1] 


01755 

Specimen ID (is usually the Container 
ID) 

3 

80 

EIP 

RE 

[0..*] 


01756 

Specimen Parent IDs 

4 

250 

CWE 

RE 

[1-1] 

0487 

01900 

Specimen Type 

6 

250 

CWE 

RE 

[0..1] 

0371 

01758 

Specimen Additives 

11 

250 

CWE 

X 

[0..*] 

0369 

01762 

Specimen Role 

14 

250 

ST 

RE 

[0..1] 


01764 

Specimen Description 

17 

26 

DR 

RE 

[0..1] 


01765 

Specimen Collection Date/Time 

18 

26 

TS 

C 

[0..1] 


00248 

Specimen Received Date/Time 

20 

1 

ID 

C 

[0..1] 

0136 

01766 

Specimen Availability 

21 

250 

CWE 

C 

[0..*] 

0490 

01767 

Specimen Reject Reason 

26 

4 

NM 

RE 

[0..1] 


01772 

Number of Specimen Containers 


830 SPM-2 Specimen ID (EIP), conditional. 

This field contains a unique identifier for the specimen, enterprise-wide. For specimen 
identification, see Pathology TF-1, Appendix B, section 5.2. 

In many laboratories where there is one specimen per container, the value of the specimen ID 
and container ID will be same. However, there are use cases in which there is more than one 
835 specimen in a container. In those situations, the value of the container ID and the specimen 
IDs will be different. 

Condition predicate: This field shall be populated in OML messages of transaction PAT-1 and 
PAT2. 

SPM-3 Specimen Parent ID (EIP), not required 

840 Specimens are sampled and processed during a laboratory’s (diagnostic) workflow. Child 
specimens are created from existing specimens by sampling. The Specimen Parent ID field 
contains the identifiers of the specimen or specimens from which the child specimen is 
sampled. 

If the Specimen is a Part, the Specimen Parent is the Patient. If the Specimen is a Tissue item 
845 in a block, the Specimen Parent is Patient\Part. If the Specimen is a Tissue item on a slide, the 
Specimen Parent is Patient\Part\Block Tissue Item. 

In case of more than one specimen in or on a container: 

If the Specimen is a collection of undistinguishable Tissue items in a block, the Specimen 
Parent is Patient\l...n Part. If the Specimen is an identified Tissue item in a block the 
850 Specimen Parent is Patient\Part. 

If the Specimen is a collection of undistinguishable Tissue items on a slide, the Specimen 
Parent is Patient\l...n (PartYBlock Tissue Item). If the Specimen is an identified Tissue item 
on a slide the Specimen Parent is Patient\Part\ Block Tissue Item. 

If the Specimen is a Tissue core in a TMA block, the Specimen Parent is 
855 Patient\Part\DonorBlock Tissue Item. If the Specimen is a Tissue spot on a TMA slide, the 
Specimen Parent is Patient\Part\DonorBlock Tissue ItemYTissue core in the TMA block. 
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SPM-4 Specimen Type (CWE), required if available. 

This field describes the precise nature of the physical object (or collection of objects) is that is 
860 the subject of one or more steps in the laboratory (diagnostic) workflow. The Specimen Type 
is a coded precise description of the specimen type (DICOM context ID ccc5), i.e “breast 
tumorectomy”. This coded description is consistent with the specimen “general” type 
(DICOM context ID ccc3) (part, tissue item, tissue section, tissue core, etc) and the general 
specimen collection procedure (DICOM context ID cclO) (aspiration, biopsy, excision, etc). 

865 The authorized values for this field are those of HL7 table 0487 - Specimen type. See HL7 
v2.5 chapter 7 (7.18.4). HL7 doesn’t suggest values for this table. The following table 
provides the DICOM values of the Context ID ccc5 (Specimen Description Codes). 


Table 3-16: DICOM Specimen Description codes. 


DICOM Value 

Description 

x05050a 

Lung Lobe Resection 

x05050b 

Prostate Resection 

x05050c 

Skin Biopsy 

x05050d 

Colon Biopsy 


SPM-14 Specimen Handling Code (CWE), Optionnal 

870 This is a text field that allows additional information specifically about the specimen to be 
sent in the message. 

SPM-17 Specimen Collection Date/Time (DR), required if available. 

Definition: The date and time when the specimen was acquired from the source. The use 

of the Date Range data type allows for description of specimens collected over a period of 
875 time, for example, 24-hour urine collection. For specimens collected at a point in time, only 
the first component (start date/time) will be populated 

SPM-18 Specimen Received Date/Time (TS), conditional. 

The time the specimen is received at the Pathology laboratory. 

Condition predicate: This field shall be populated in OML and ORU messages sent by the 
880 Order Filler, within transactions PAT-1 (all use cases), PAT-2 and PAT-3, if the specimen has 
been received by the Pathology. In other words this field is RE for the order filler actor in 
both transactions PAT-1, PAT-2 and PAT-3. 

SPM-20 Specimen Availability (ID), conditional. 

This describes whether the specimen, as it exists, is currently available to use in an analysis. 
885 The two authorized values are "Y" (yes) or "N" (no). 

Condition predicate: This field shall be populated in OML messages sent by the Order Filler, 
within transactions PAT-1 (all use cases) and PAT-2. The value 'N' indicates either that the 
Pathology hasn't received the specimen yet, or that it has rejected the received specimen. In 
other words this field is RE for the order filler actor. The value of this field can be implicitly 
890 derived from ORC-5 (e.g. ORC-5 = ‘IP’ implicitly means that the specimen has arrived, 
otherwise the test could not be in progress). 

This field is pointless in messages sent by the Order Placer. 

SPM-21 Specimen Reject Reason (CWE), conditional. 

This describes one or more reasons the specimen is rejected for the ordered batteries 
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895 Condition predicate: This field shall be populated in OML messages sent by the Order Filler 
in transaction PAT-1, whenever the Pathology rejects a specimen. 

Refer to HL7 Table 0490 - Specimen Reject Reason for valid values. 


T able 3-17: Values for Specimen Reject Reason . 


Value 

Description 

Comment 

EX 

Expired 


QS 

Quantity not sufficient 


RB 

broken container 


RD 

missing collection date 


R 

missing patient ID number 


RE 

missing patient name 


RI 

Identification problem 


RL 

Improper labeling 


RM 

Labeling 


RR 

improper storage 


RS 

name misspelling 



900 SPM-26 Number of Specimen Containers (NM), required if available. 

HL7 Definition: This field identifies the number of containers for a given specimen. For 
sample receipt verification purposes; may be different from the total number of specimens 
that accompany the order. 

3.10 SAC Container Detail segment 

905 HL7 v2.5: chapter 13 

The IHE Pathology Technical Framework defines the usage of 2 SAC fields; it allows all 
other fields to be optionally used. 


Table 3-18: SAC - Container Detail segment. 


SEQ 

LEN 

DT 

Usage 

Card. 

TBL# 

ITEM# 

Element name 

1 

80 

El 

O 

[1-1] 


01329 

External Accession Identifier 

2 

80 

El 

O 

[1-1] 


01330 

Accession Identifier 

3 

80 

El 

R 

[1-1] 


01331 

Container Identifier 

4 

80 

El 

C 

[0..1] 


01332 

Primary (parent) Container Identifier 

6 

300 

SPS 

X 

[0..0] 


00249 

Specimen Source 


Condition for the use of the SAC segment: The SAC segment should be used only if the 
910 number of containers differs from the number of specimens (e.g. a specimen is split in several 
containers or multiple specimens placed in or on the same container). Otherwise, when there 
is one container for one specimen the SPM segment is sufficient and the SPM-2 Specimen ID 
provides both the specimen/container identifier. 

In case of multiple specimens placed in or on the same container, the message will contain as 
915 many SPM segment as specimens. All SPM segments will have the same Container ID but 
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different Specimen ID. In case of a specimen split between several containers, the SPM 
segments will include multiple SAC segments with different Container ID. 

SAC-3 - Container Identifier (El), required. 

SAC-3 field identifies the container. This field is the container's unique identifier assigned by 
920 the Order Placer. A container may contain the primary (original) specimen or an aliquot 
(secondary sample) of that specimen. For primary sample this field contains Primary 
Container ID; for bar-coded aliquot samples this field contains Aliquot Container ID. 

SAC-4 - Primary (parent) Container Identifier (El), conditional. 

Condition predicate: This field is used only in transactions PAT-1 and PAT-2 when dealing 
925 with a specimen that is split between several containers. In this case, SAC-3 and SAC-4 are 
used simultaneously as described below: 

If SAC-4 field is filled in, it identifies the primary container from which this specimen came. 
For primary samples this field is empty; for aliquot samples this field should contain the 
identifier of primary container. 

930 3.11 Correlations of status between ORC, OBR, OBX 

Semantics of the main status code associations 

In HL7 version 2.5 a change in the status of an observation is identified by a combination of 
the Trigger Event field contained in segment MSH, the ORC-5 (Filler Order status) field, the 
OBR-25 (Order Result Status) field and the OBX. 11 (Observation Result Status) field. OBX- 
935 11 contains the status of an individual test, OBR-25 the status of the entire request. 


940 


945 


950 
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955 Table 3-19: Correlation of status. 


Order 

Table 0038 
(ORC-5) 

Request 
Table 0123 
(OBR-25) 

Result 

Table 0085 
(OBX-11) 

Description (combined from 3 tables) 


O 

O 

Order received; specimen not yet received. Order 
detail description only (OBX contains no result). 
This value should only be used in ORL event 
acknowledgment messages. It should not be used 
in OML messages. 

SC 

S 


No results available; procedure scheduled, but 
not done. The specimen may not have arrived at 
the laboratory. No OBX is present 

IP 

I 

I 

In process; The specimen is available in the 
laboratory; results are pending; the procedure is 
incomplete 



D 

Deletes the OBX record 

A 

R 

R 

(Some) results entered — not yet verified 

A 

P 

P 

(Some) preliminary verified results. The final 
results are not yet obtained 

CM 

F 

F 

Final results; results stored and verified. Can 
only be changed with a corrected result. 

(CM) 

C 

C 

Record coming over is a correction and thus 
replaces a final result 

CA 

X 

X 

(OBX) Results cannot be obtained for this 
observation. (ORC/OBR) No results available; 
Order canceled. 


Note: the status codes used in ORC-5 are less ‘atomic’ than those used in OBR-25/OBX-11. 
If there is no direct ‘semantic match’ the ORC-5 column lists the closest equivalent between 
braces. 


The table shown above contains a description of the semantics of the code values used by 
960 these fields. Please note that this table does not identify all possible relationships of the 
various status fields. The relationship between the various statuses fields are described below. 
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4 Transaction PAT-1: Placer Order Management 

4.1 Scope 

Transaction PAT-1 is used by the Order Placer to place a new order to the Order Filler. 
965 Macroscopic and microscopic examinations of specimen(s) collected from a patient are 
ordered by a Physician or Surgeon. Each specimen is collected and placed in a container that 
is labeled with the specimen ID (possibly in a barcode format). 

The main goal of the Placer Order Management Transaction is to allow consistent 
management of the content and status of the order between the Order Placer and Order Filler 
970 actors. 

4.2 Use Case Roles 



Actor: Order Placer 

975 Roles: Places orders. Updates orders, cancels orders and receives acceptance or rejection 
from the Order Filler. Receives order related changes from the Order Filler. 

Actor: Order Filler 

Roles: Receives orders, checks the specimens required and notifies the Order Placer of 
acceptance or refusal. Receives order related changes from the Order Placer. Notifies content 
980 updates (removed procedures) to the Order Placer. Notifies the progression (scheduled, 
started, cancelled, completed) to the Order Placer. 


4.3 Referenced standards 

HF7 version 2.5: 

• Chapter 2: "Control" — > generic segments and data types 

985 • Chapter 3: "ADT" —> PID and PV1 segments 

• Chapter 4: "Order Entry" — > OMF and ORE messages 

• Chapter 7: "Observation Reporting" —> SPM segment 

• Chapter 13: "Clinical Pathology Automation" — > SAC segment 


990 4.4 Interaction diagrams 

Since Pathology request can involve several specimens and a specimen may be divided in 
several pieces that need to be clearly identified and transported in distinct containers, the most 
appropriate message for Pathology orders is the 0MF A 021 message. This message contains: 
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• a list of ordered procedures; 

995 • a list of specimens underneath each procedure; 

• a list of containers underneath each procedure. 

Observation result segments may be added after each procedure for providing the Order Filler 
with all additional details that are necessary for performing the fulfilling the order. 

In all interaction diagrams below, the initiator transmits an 0ML A 021 message, the responder 
1000 SHALL respond with an application acknowledgement message 0RL A 022. 
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4.4.1 Normal process of a placer order 

The figure below shows the flow of messages in the normal process of a placer order, from 
placing of the order by the Order Placer, to the "order completed" event notified by the Order 
1005 Filler. 


Order Placer 


Order Filler 




Placement of 
a new order 


OML New Order: ORC-1 = NW 


ORL Order accepted: ORC-1 = OK 
Unable to accept: ORC-1 = UA 


OML procedure replaced: ORC-1 = RU 


procedure canceled: ORC-1 = OC 


u 


ORL acknowledgement: ORC-1 = OK 


OML Status changed: ORC-1 = SC 


ORL acknowledgement: ORC-1 = OK 


□ Replacement 
of an order 


ORL Replaced as requested: ORC-1 = RQ 
Unable to replace: ORC-1 = UM 


4 


Placer order checked with the 
-®- related specimens. Some 

procedure may be replaced or 
canceled 


□ 


Status of the order changed 


OML Replace Order: ORC-1 = RP 


A 


Figure 4-1: Normal process of a placer order. 
4.4.2 Cancellation of an order by the Order Placer 


Order Placer 


Order Filler 


1010 



Placer order 
cancelled 

OML Cancel order request: ORC-1 = CA 

ORL acknowledgement _ 

Cancelled as requested: ORC-1 = CR 
Unable to cancel: ORC-1 = UC 


For each procedure, the 
cancel request is accepted or 
refused (if the processing has 
already started) 


Figure 4-2: Cancellation of an order by the Order Placer. 

The Order Filler accepts the cancellation only if the processing has not started yet. 


1015 
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1020 


1025 


1030 


4.4.3 Cancellation of an order initiated by the Order Filler 



Figure 4-3: Cancellation by the Order Filler. 


4.5 Messages static definitions 

4.5.1 Restrictions on OML A 021 message for transaction PAT-1 

This cycle of Pathology Technical Framework makes the following restrictions for transaction 

PAT-1: 

• PAT-1 carries all clinical observations provided by the Care Unit, such as medical 
information, specific ordering questionnaires, within observation segments (OBX) that 
accompany the order. This choice has been made to simplify the building and parsing 
of the messages. All these specific patient observations are sent in the OML message, 
in OBX segments. 

• PAT-1 restrains timing/quantity to one execution per order. 


4.5.2 OML A 021 - static definition 

_ Table 4-1: OML A Q21 message description. 


Segment 

Meaning 

Usage 

Card. 

HL7 chapter 

MSH 

Message Header 

R 

[1-1] 

2 

[ 

— PATIENT begin 

RE 

[0..1] 


PID 

Patient Identification 

R 

[1-1] 

3 

[ pvi ] 

Patient Visit 

RE 

[0..1] 

3 

] 

— PATIENT end 




{ 

— ORDER begin 

R 

[1..*] 


ORC 

Common Order (for one battery) 

R 

[1-1] 

4 

[ TQ1 ] 

Timing Quantity 

RE 

[0..1] 

4 


— OBSERVATION REQUEST begin 

R 

[1-1] 


OBR 

Observation Request 

R 

[1-1] 

4 

{ [NTE] } 

Notes and Comments 

O 

[0..*] 

2 

[{ 

— OBSERVATION begin 

O 

[0..*] 


OBX 

Observation Result 

R 

[1-1] 

7 

[{NTE}] 

Comment of the result 

C 

[0..*] 

2 
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}] 

— OBSERVATION end 




[{ 

— SPECIMEN begin 

O 

[0..*] 


SPM 

Specimen 

R 

[1-1] 

7 

[{SAC}] 

Container 

C 

[2..*] 

13 

}] 

— SPECIMEN end 





— OBSERVATION REQUEST end 




} 

— ORDER end 





Field MSH-9 - Message Type (MSG) shall have its three components respectively valued to 
“OML”, “021” and “0ML_021”. 

The triplet (ORC, TQ1, OBR) represents the order (i.e. an ordered battery/test). This triplet is 
1035 repeated as many times as the number of batteries/procedure contained in the order group. 

The OBSERVATION (OBX) repeatable segment group carries the observations provided by 
the order placer. 

Condition predicate for the SAC segment: See the common definition of the SAC segment in 
section 3.10. 

1040 4.5.3 0RL A 022 static definition 


Table 4-2: 0RL A 022 message description. 


Segment 

Meaning 

Usage 

Card. 

HL7 chapter 

MSH 

Message Header 

R 

[1-1] 

2 

MSA 

Message Acknowledgment 

R 

[1 — 1] 

2 

[ {ERR} ] 

Error 

C 

[0..*] 

2 

[PID] 

Patient Identification 

O 

[0..1] 

3 

{ 

— ORDER begin 

R 

[1..*] 


ORC 

Common Order 

R 

[1—1] 

4 

[ {TQ1} ] 

Timing Quantity 

RE 

[0..1] 

4 


— OBSERVATION REQUEST begin 

R 

[1-1] 


OBR 

Observation Request 

R 

[1-1] 

4 

[{ 

— SPECIMEN begin 

O 

[0..*] 


SPM 

Specimen 

R 

[1—1] 

7 

[{SAC}] 

Container 

C 

[2..*] 

13 

}] 

— SPECIMEN end 





— OBSERVATION REQUEST end 




} 

— ORDER end 





MSH-9 - Message Type (MSG) shall have its three components respectively valued to 
“ORL”, “022” and “0RL_022”. 

The ERR segment shall be used in case of negative acknowledgement (when MSA-1 = AE or 
1045 AR). 
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1050 


4.5.4 Specific segments description for transaction PAT-1 


4.5.4.1 OBR - Observation Request segment 

HL7 v2.5: chapter 4 (4.5.3) 


Table 4-3: OBF 

! - Observation F 

equest segment. 

SEQ 

LEN 

DT 

Usage 

Card. 

TBL# 

ITEM# 

Element name 

2 

22 

El 

R 

[1-1] 


00216 

Placer Order Number 

3 

22 

El 

RE 

[0..1] 


00217 

Filler Order Number 

4 

250 

CE 

R 

[1-1] 


00238 

Universal Service Identifier 

5 

2 

ID 

X 

[0..0] 


00239 

Priority - OBR 

6 

26 

TS 

X 

[0..0] 


00240 

Requested Date/Time 

7 

26 

TS 

X 

[0..0] 


00241 

Observation Date/Time # 

8 

26 

TS 

X 

[0..0] 


00242 

Observation End Date/Time # 

9 

20 

CQ 

X 

[0..0] 


00243 

Collection Volume * 

10 

250 

XCN 

RE 

[0..*] 


00244 

Collector Identifier * 

11 

1 

ID 

RE 

[0..1] 

0065 

00245 

Specimen Action Code * 

12 

250 

CE 

X 

[0..0] 


00246 

Danger Code 

13 

300 

ST 

X 

[0..0] 


00247 

Relevant Clinical Information 

14 

26 

TS 

X 

[0..0] 


00248 

Specimen Received Date/Time * 

15 

300 

SPS 

X 

[0..0] 


00249 

Specimen Source 

16 

250 

XCN 

R 

[1-1] 


00226 

Ordering Provider 

17 

250 

XTN 

RE 

[0..2] 


00250 

Order Callback Phone Number 

18 

60 

ST 

X 

[0..0] 


00251 

Placer Field 1 

19 

60 

ST 

X 

[0..0] 


00252 

Placer Field 2 

20 

60 

ST 

X 

[0..0] 


00253 

Filler Field 1 + 

21 

60 

ST 

X 

[0..0] 


00254 

Filler Field 2 + 

22 

26 

TS 

X 

[0..0] 


00255 

Results Rpt/Status Chng - Date/Time 
+ 

23 

40 

MOC 

X 

[0..0] 


00256 

Charge to Practice + 

24 

10 

ID 

C 

[0..1] 

0074 

00257 

Diagnostic Serv Sect ID 

25 

1 

ID 

C 

[0..1] 

0123 

00258 

Result Status + 

26 

400 

PRL 

X 

[0..0] 


00259 

Parent Result + 

27 

200 

TQ 

X 

[0..0] 


00221 

Quantity/Timing 

28 

250 

XCN 

C 

[0..*] 


00260 

Result Copies To 

29 

200 

EIP 

X 

[0..0] 


00261 

Parent 

30 

20 

ID 

X 

[0..0] 

0124 

00262 

Transportation Mode 

37 

4 

NM 

X 

[0..1] 


01028 

Number of Sample Containers * 

40 

250 

CE 

X 

[0..0] 


01031 

Transport Arrangement 

Responsibility 
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SEQ 

LEN 

DT 

Usage 

Card. 

TBL# 

ITEM# 

Element name 

41 

30 

ID 

X 

[0..0] 

0224 

01032 

Transport Arranged 

42 

1 

ID 

X 

[0..0] 

0225 

01033 

Escort Required 

43 

250 

CE 

X 

[0..0] 


01034 

Planned Patient Transport Comment 

48 

250 

CWE 

X 

[0..0] 

0476 

01646 

Medically Necessary Duplicate 
Procedure Reason. 


OBR-2 Placer Order Number (El), required in transaction PAT-1. 

Note that all batteries/procedure contained in the order should be assigned a unique Placer 
Order Number. The same identifier will never be used twice by the Order Placer. The Placer 
Order Number is generated by the Order Placer actor and should be unique across all OBR 
1055 segments across all messages. 

OBR-3 Filler Order Number (El), required if available. 

Note that all batteries/procedure contained in the filler order should be assigned a unique 
Filler Order Number. The same identifier will never be used twice by the Order Filler. The 
filler order number is generated by the Order Filler actor and should be unique across all OBR 
1060 segments across all messages. 

OBR-4 Universal Service Identifier (CE), required. 

This field contains one ordered battery or procedure. 

OBR-5 Priority and OBR-6 Requested Date/Time 

These two fields are not supported. See TQ1 segment. 

1065 OBR-7, OBR-8, OBR-12, OBR-14, and OBR-15 These fields are not supported. See SPM 
segment that supersedes them. 

OBR-10 Collector Identifier, required if available. 

This repeatable field contains the specimen collectors’ identification. 

OBR-11 Specimen Action Code (ID), required if available. 

1070 The value of this field is dependent on the use case as described in Volume 1. 

The field identifies the action to be taken with respect to the specimens that accompany or 
precede this order. The purpose of this field is to further qualify (when appropriate) the 
general action indicated by the order control code contained in the accompanying ORC 
segment. HL7 Table 0065 - Specimen Action Code gives the valid values: 

1075 __ Table 4-4: Specimen Action Code. _ 


Value 

Description 

Comment 

A 

Add ordered tests to the existing specimen 


G 

Generated order; reflex order 


L 

Lab to obtain specimen from patient 


O 

Specimen obtained by service other than Lab 


P 

Pending specimen; Order sent prior to delivery 


R 

Revised order 


S 

Schedule the tests specified below 
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OBR-13 Relevant Clinical information (ST), not supported. 

Transaction PAT-1 uses OBX segment to carry relevant clinical information, or a NTE 
segment below the OBR for more comment orientated information. 

1080 OBR-16 Ordering Provider (XCN), required. 

This field identifies the provider who ordered the test. Either the ID code or the name, 
or both, may be present. This is the same as ORC-12-ordering provider. 

OBR-17 Order Callback Phone Number (XTN), required if available; contains one or two 
phone numbers. 

1085 OBR-22 Results Rpt/Status Chng - Date/Time (TS), not used in PAT-1. 

OBR-22 is related to the RESULT, not to the ORDER. OBR-22 is related to OBR-25. ORC-9 
contains the date/time of the latest status change of the ORDER. 

OBR-24 Diagnostic Serv Sect ID (ID), conditional 

Condition predicate: This field may be valued in OML messages sent by the Order Filler. In 
1090 other words this field is RE for the order filler actor. The valid values are defined in HL7 
Table 0074 - Diagnostic Service Section ID. The only values applicable for Pathology 
Technical Framework are listed below. 


Table 4 

1-5: Diagnostic Service Section ID (subset). 

Value 

Description 

Addressed by Pathology TF 

CP 

Cytopathology 

Yes 

OSL 

Outside Lab 

Yes 


OBR-25 Order Result Status (ID), conditional 

1095 Condition predicate: This field shall not be filled in messages sent by the Order Placer. This 
field shall be filled in messages sent by the Order Filler, according to HL7 Table 0123 
described in Chapter 7 of HL7. In this version of the Pathology Technical Version, the 
possible values for this field are a subset of this table: 


Table 4-6: Result Status. 


Value 

Description 

Comment 

O 

Order received; specimen not yet received 


I 

No results available; specimen received, procedure 
incomplete 


s 

No results available; procedure scheduled, but not done 


R 

Results stored; not yet verified 


P 

Preliminary: A verified early result is available, final 
results not yet obtained 


F 

Final results; results stored and verified. Can only be 
changed with a corrected result. 


C 

Correction to results 


X 

No results available. Order canceled 



1100 
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Note: for the conditions of use of these values, please read section 3.11 “Correlations of 
status between ORC, OBR and OBX”. 

OBR-28 Result Copies To (XCN), conditional. 

HL7 Definition: This field identifies the people who are to receive copies of the results. By 
1105 local convention, either the ID number or the name may be absent. 

Condition predicate: The Order Placer shall fill this field when it sends a new order for which 
there are persons or care units declared for receiving a copy of the results. 

4.5.4.2 OBX - Observation/Result segment 

HL7 v2.5: chapter 7 (7.4.2) 

1110 ___ Table 4-7: OBX - Observation/Result segment. _ 


SEQ 

LEN 

DT 

Usage 

Card. 

TBL# 

ITEM# 

Element name 

1 

4 

SI 

R 

[1-1] 


00569 

Set ID - OBX 

2 

2 

ID 

C 

[0..1] 

0125 

00570 

Value Type 

3 

250 

CE 

R 

[1-1] 


00571 

Observation Identifier 

4 

20 

ST 

C 

[0..1] 


00572 

Observation Sub-ID 

5 

99999 

Varies 

C 

[0..1] 


00573 

Observation Value 

11 

1 

ID 

R 

[1-1] 

0085 

00579 

Observation Result Status 

14 

26 

TS 

RE 

[0..1] 


00582 

Date/Time of the Observation 

15 

250 

CE 

RE 

[0..1] 


00583 

Producer's ID 

16 

250 

XCN 

RE 

[0..1] 


00584 

Responsible Observer 

17 

250 

CE 

C 

[0..1] 


00936 

Observation Method 


OBX-1 Set ID - OBX (SI), required. 

This field contains the sequence number of the OBX. 

OBX-2 Value Type (ID), required. 

This field contains the format of the observation value in OBX. It must be valued if OBX-11- 
1115 Observation Result Status is not valued with an “X”. 

The Value Type field should be filled according to HL7 Version 2.5 standard (table 0125). 

OBX-3 Observation Identifier (CE), required 

The usage of LOINC(r) test codes for the identification of tests is strongly recommended. 
Details of this free vocabulary can be found at http://www.loinc.org . 

1120 The first and third sub-fields “Identifier”, and “Name of Coding System” are required in all 
transactions. The value of the “Name of Coding System” in the case of LOINC is “LN”. 

In transaction PAT-3 the second sub-field “Text” is mandatory, which allows the Order 
Result Tracker to manage the results without the help of a Test Master File. 

The last three sub-fields are optional in all transactions. 

1125 OBX-4 Observation Sub-ID (ST), conditional. 

Condition predicate: This field shall be used to distinguish between multiple OBX segments 
with the same observation ID organized under one OBR. 
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See HL7 V2.5 (7.4.2) for details and examples. 
OBX-5 Observation Value (varies), conditional. 


1130 


1135 


1140 


Condition predicate: This field is required unless the Observation Result Status field (OBX- 
11) is valued either with "D", or "I" or "X". The Observation Value field shall be valued 
accordingly to the definition made in Chapter 7 of HL7 2.5 version. 

OBX-11 Observation Result Status (ID), required. 


This field contains the observation result status. Refer to HL7 table 0085 - Observation result 
status codes interpretation for valid values. This field reflects the current completion status of 
the results for one Observation Identifier. The only values applicable for transaction PAT-1 of 
Pathology Technical Framework are listed below: 


Table 4-8: Observation result status codes for PA 


Value 

Description 

F 

Final results; Can only be changed with 
a corrected result. 


OBX-14 Date/Time of the Observation (TS), required if available. 


This field should be valued when the OBX-5 field (Value field) is also valued. 


OBX-15 Producer's ID (CE), required if available. 

This field is required in case the observation was not produced by the sending organization. 
OBX-16 Responsible Observer (XCN), required if available. 

This field is required when the observation result status (OBX-11) is valued with "D" or "R" 
1145 or "P" or "F" or "C" or "X" and the Producer's ID field is not valued. It should contain the 
identity of the observer that causes the change of the observation result status. Only the first 
component (ID number) of this field is necessary, provided that it is possible to retrieve the 
full identity of responsible person in the Order Filler system with only this ID number. 

OBX-17 Observation Method (CE), conditional. 


1150 Condition predicate: This field is required when the value of the result may be dependant of 
the Observation Method and the Observation Identifier does not permit to identify the 
Method. With some Observation Identifiers such as LOINC(r) Codes, the identifier also 
identifies the Method, in which case this field does not need to be valued. 
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1155 5 Transaction PAT-2 - Filler Order Management 

5.1 Scope 

This transaction is used by the general use case “ Filler order with specimens identified by 
third party or collected by the laboratory ” described in the Volume 1 of this technical 
framework. It corresponds to transaction PAT-2 of the IHE Pathology Framework. It is used 
1160 by the Order Filler (Faboratory Information System) and the Order Placer. 

This transaction is used when a new order or a new battery is placed at the Order Filler level 
in order to require the Order Placer to allocate a Placer Order Number to this new order. The 
order contains the list of batteries or tests for which the Order Placer should allocate an order 
number 

1165 The main goal of the Filler Order Management Transaction is to allow consistent 
management of the order, (content and status), between the Order Filler and Order Placer 
actors, this allowing the Order Placer to manage invoicing. 

5.2 Use Case Roles 



1170 Actor: Order Placer 

Roles: Receives filler orders. Notifies the Order Filler of acceptance or refusal. Notifies the 
Order Filler of the placer order number if the filler order was accepted. 

Actor: Order Filler 

Roles: Places filler orders by sending them to the Order Placer. Receives acceptance or 
1175 rejection from the Order Placer. Receives the placer order reference number from the Order 
Placer if the Order Placer accepts the order. Receives order related changes from the Order 
Placer. 


5.3 Referenced Standards 

HF7 version 2.5: 

1180 • Chapter 2: "Control" — > generic segments and data types 

• Chapter 3: "ADT" — > PID and PV1 segments 

• Chapter 4: "Order Entry" — > OMF and ORE messages 

• Chapter 7: "Observation Reporting" —> SPM segment 

• Chapter 13: "Clinical Faboratory Automation" —> SAC segment 

1185 
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5.4 Interaction Diagrams 

For the same reasons exposed in § 4.4, in all interaction diagrams below, the initiator 
transmits an OML A 021 message, the responder SHALL respond with an Application 
acknowledgement message 0RL A 022. 

5.5 Messages Static Definition 

The figure below shows the flow of messages in the normal process of a Filler Order. A Filler 
Order is placed, and responded to by either a rejection or acceptance. 

Note that the creation of a Filler Order may be triggered by a prior Placer Order, e.g. if the 
results of one of the previously ordered tests triggers the laboratory to perform additional 
tests. The creation of a Filler Order could also happen during the control performed by the 
laboratory on a new order received from the Order Placer: the laboratory may then decide that 
some extra battery that was not ordered should be added, e.g. regarding the pathology context. 


Order Placer 


Order Filler 


OML Send order/service number: ORC-1 = SN 


ORL acknowledgement _^ 

Number assigned: ORC-1 = NA 
Unable to accept order: ORC-1 = UA 

Figure 5-1: Process of a filler order. 

Since the purpose of this transaction is to require a Placer Order Number to the Order Placer 
for orders that are placed or added at the Order Filler level, there is no real need to support the 
SPM and SAC segments in the messages associated to this transaction. 

The SPM and SAC segments should then be considered as optional in the transaction PAT-2. 

For requesting a Placer Order number the Order Filler will transmit an OML A 021 message in 
which the ORC-1 field (Order Control ID) will contain "SN" (Send Number). In this message 
the Placer Order Number fields in ORC-2 and OBR-2 should be empty. 

The Order Placer will acknowledge with an ORL message in which the ORC-1 field will 
contain the value "NA" (Number Assigned). The Order Placer should supply the Placer Order 
Number assigned to this order in the ORC-2 and OBR-2 fields. 


rui cacn uaiiciy, me 

filler order is accepted 
or rejected. In case of 
acceptance the Placer 
Order is reported to 
the Order Filler. 


□ Creation of a 
new filler order 
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6 Transaction PAT-3 - Order Results Management 

This section corresponds to Transaction 3 of the IHE Pathology Technical Framework. It is 
used by the Order Filler and the Order Result Tracker. 

6.1 Scope 

This transaction notifies the Order Result Tracker of requested tests upon creation of an order 
or reception of a specimen in the laboratory. It transmits the observation results and reports 
from the Order Filler to the Order Result Tracker, when a result is acquired, clinically 
validated, modified or deleted at the Order Filler level. Another goal of this transaction is to 
provide the Order Result Tracker with the complete sorted set of results related to a placer 
order or a placer order group. The Order Result Tracker shall store these results in the sorting 
order given by the Order Filler. 

In order to maintain consistency between order and result messages, the result messages of 
transaction PAT-3 should refer to primary specimen even in the case where some of the 
observations are performed on secondary samples that are derived from primary specimen 
after specific preparation. 

This transaction is also used by the Order Filler to send structured or non-structured 
documents to the Order Result Tracker. Reports can be an unstructured document (RTF, GIF 
image, PDF) or a structured document (for example: HF7 CDA). The document is not 
transmitted in the message itself. The HF7 message contains a link to the document 
(repository, ftp site ...). 

6.2 Use Case Roles 



Actor: Order Filler 

Roles: Provides notification to the Order Result Tracker for specimen arrival, acquisition of 
technically validated results, clinical validation of results, changing/cancellation of results. 
Provides the complete sorted set of results related to a placer order or a placer order groups. 
Results can be provided as a report. 

Actor: Order Result Tracker 

Roles: Receives test order, results and reports from the Order Filler, gives access to this order 
and results to the healthcare enterprise, respects the sorting order of the results as received 
from the Order Filler. 

6.3 Referenced Standards 

HF7 version 2.5: 

• Chapter 2: "Control" — > generic segments and data types 

• Chapter 3: "ADT" —> PID and PV1 segments 
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• Chapter 7: "Observation Reporting" —> ORU A R01 

6.4 Interaction Diagram 

1250 Since Pathology request can involve several specimens and a specimen may be divided in 
several pieces that need to be clearly identified and transported in distinct containers, the most 
appropriate message for Pathology results is the ORU A R01 message. This message is a 
battery-centric structure. 

6.4.1 Normal process for management of results of a filler order 

1255 The figures below show the flow of messages that occurs during normal process of a filler 
order, from the reception of specimen or entry of the order in the laboratory, up to the 
completion of this order and visualization of results by an end user on the Order Result 
Tracker. For each triggering event of an ORU message, the value of the result status of the 
OBR (OBR-25) is indicated. 


1260 


Older Filler 


Order Result 



Tracker 


New order received or 
created 

QRU A R01, OBR-25 = S 


ACK ("aDDlication acknowledgement") 


Reception or acceptance of a 
specimen 

ORU A R01, OBR-25 = I 

ACK (aoDlication acknowledgement") 


Technically validated results or 
reports) available 

ORU A R01, OBR-25 =R 

ACK (application acknowledgement) 


Clinical validation of results or 
reports) 

ORU A R01, OBR-25 = P (Partial) or F (Final) 

ACK (application acknowledgement) 


Correction of results or report(s) previously sent 
as clinically validated 

ORU A R01, OBR-25 = C 

ACK (application acknowledgement) 


Figure 6-1: Interaction diagram of the PAT-3 transaction. 

An Order Filler will trigger an Unsolicited Observation Message when the following events 
occur: 


1265 


• entry of an order at the Laboratory level for a collected specimen; 

• reception and acceptance of a specimen; 

• intermediate results or reports; 

• clinically validated results or reports; 

• modification of an existing transmitted validated result or report; 

• cancellation of a result or a report. 
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1270 6.5 Message Static Definition 

6.5.1 ORU A R01 - Unsolicited Observation Message 


Table 6-1: ORU A RQ1 message description. 


Segment 

Meaning 

Usage 

Card. 

HL7 chapter 

MSH 

Message Header 

R 

[1-1] 

2 

[ 

— PATIENT begin 

O 

[0..1] 


PID 

Patient Identification 

R 

[1-1] 

3 

[ pvi ] 

Patient Visit 

RE 

[0..1] 

3 

] 

— PATIENT end 




{ 

— ORDER_OB SERVATION begin 

R 

[1..*] 


ORC 

Common Order (for one battery) 

R 

[1—1] 

4 

OBR 

Observation Request 

R 

[1—1] 

4 

[ {TQ1} ] 

Timing Quantity 

RE 

[0..1] 

4 

[{ 

— OBSERVATION begin 

O 

[0..*] 


OBX 

Observation Result 

R 

[1—1] 

7 

[ { NTE } ] 

Comment of the result 

C 

[0..*] 

2 

}] 

— OBSERVATION end 




[{ 

— SPECIMEN begin 

O 

[0..*] 


SPM 

Specimen 

R 

[1-1] 

7 

[{OBX}] 

Observation related to specimen 

C 

[2..*] 

13 

}] 

— SPECIMEN end 




} 

— ORDER_OBSERVATION end 





Field MSH-9 - Message Type shall have its three components valued as follows: 
ORU A RO1 A ORU_RO 1. 

1275 Following the ORC/OBR, the Order Filler should systematically transmit in the message, all 
OBX and SPM segments related to this ORC/OBR. This systematic transmission of all 
observations linked to an OBR and their respective status may help the Order Result Tracker 
to recover from error situations. 

For the same reason the "U" value should not be used in the Observation Result Status field of 
1280 an OBX segment (see description of this segment earlier in this document). 

For multi-specimen orders, each specimen of the order is described in an SPM segment. The 
tests performed on that specimen shall have their observations reported in OBX segments 
following the SPM. 

Links to report are sent as a result in OBX segments. If a report is related to an individual 
1285 specimen, it shall be sent in an OBX segment following the SPM. If a report is global to the 
order, it shall be sent in an OBX segment following the ORC/OBR segments. 

In case an observation previously transmitted is deleted, the Order Filler should transmit all 
OBX segments linked to the OBR to which the deleted observation relates to; and it should 
indicate the current status of each OBX segment. The Observation Result Status field of 
1290 theOBX that correspond to the deleted observation should be valued with a "D". 
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6.5.2 Specific segments description for transaction PAT-3 


1295 


6.5.2.1 OBR - Observation Request segment 

HL7 v2.5: chapter 4 (4.5.3). 


The ORU message shall contain only one OBR segment corresponding to the analysis of a 
specimen or a group of related specimen. The OBR segment is described in Table 4-3 for 
transaction PAT-1. The following table shows the difference with PAT-3 only. 


Table 6-2: OBR - Observation Request segment. 


SEQ 

LEN 

DT 

Usage 

Card. 

TBL# 

ITEM# 

Element name 

2 

22 

El 

RE 

[0..1] 


00216 

Placer Order Number 

3 

22 

El 

R 

[1-1] 


00217 

Filler Order Number 

4 

250 

CE 

R 

[1-1] 


00238 

Universal Service Identifier 


OBR-2 Placer Order Number (El) 


1300 This field is required if the value is known to the sender. 

OBR-3 Filler Order Number (El), required. 

This field is required. It allows the Order Filler to link all the observations and reports of a 
request together. It also identifies the order at the Order Filler level. 

OBR-4 Universal Service Identifier (CE), required. 

1305 The first three sub-fields “Identifier”, “Text” and “Name of Coding System” are required. The 
second sub-field “Text” allows the Order Result Tracker to manage the observations and 
reports without the help of an Order Master File. 


6.5.2.2 OBX - Observation/Result segment 

HL7 v2.5: chapter 7 (7.4.2). 

1310 The OBX segment contains the observations and the links to the Pathology reports. The 
following table shows the difference with PAT-1 only. 


1 

rable 6-2 

1: OBX 

- Observation/Result segment. 

SEQ 

LEN 

DT 

Usage 

Card. 

TBL# 

ITEM# 

Element name 

2 

2 

ID 

C 

[0..1] 

0125 

00570 

Value Type 

3 

250 

CE 

R 

[1-1] 


00571 

Observation Identifier 

5 

99999 

ST 

R 

[0..1] 


00573 

Observation Value 

11 

1 

ID 

R 

[1-1] 

0085 

00579 

Observation Result Status 

13 

20 

ST 

C 

[0..1] 


00581 

User Defined Access Checks 


OBX-2 Value Type (ID), conditional. 


Condition predicate: this field shall be valued if OBX-5 (Observation Value) is populated. 
1315 When a report is attached to the message, OBX-2.1 is valued with RP (Reference Pointer) and 
OBX-2.4 is valued with the format of the document. Valid values are listed in HL7 Table 
0291 - Subtype of referenced data. 
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1320 __ Table 6-4: Exemple of subtypes. 


Value 

Description 

Comment 

HTML 

Hypertext Markup 
Language 


RTF 

Rich Text Lormat 


x-hl7-cda- 

level-one 

HL7 Clinical Document 
Architecture Level One 
document 


x-hl7-cda- 

level-two 

HL7 Clinical Document 
Architecture Level Two 
document 

This value is not listed in HL7 Table 0291. 

PDF 


This value is not listed in HL7 Table 0291. 

WAV 


This value is not listed in HL7 Table 0291. 


OBX-3 Observation Identifier (CE), required. 


The usage of LOINC(r) test codes for the identification of tests is strongly recommended. 
Details of this free vocabulary can be found at http://www.loinc.org. For example, the LOINC 
codes for Gross Pathology and Microscopic Pathology are 22634-0 and 22637-5, respectively. 

1325 OBX-5 Observation Value (ST), required. 

This field contains the URL to the document. The syntax of the URL must follow the RFC 
1738 and 1808. Example: file://machine/c:/report.pdf. 

OBX-11 Observation Result Status (ID), required. 

This field should be filled according to HL7 Table 0085 described in Chapter 7 of HL7. In 
1330 this version of the Pathology Technical Framework, the possible values for this field are a 
subset of the following table. 


Table 6-5: Observation result status. 


Value 

Description 

Comment 

D 

Deletes the observation or the 
report 

This status should be used when the Order Filler 
wants to cancel a false observation or report 
transmitted in a former message, in the situation 
where the right observation or report is still 
pending. The report should never be shown to 
clinical users. 

P 

Preliminary observation or 
report 

The observation or the report is clinically 
validated but it can still change. 

F 

Final observation or report 

The observation or the report can only be 
changed with a corrected value. 

C 

The observation or the report 
coming over is a correction and 
thus replace a final observation 
or report 

This status may be used only after a F or a C 
status. 

X 

Observation or report cannot be 
obtained 
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OBX-13 User Defined Access Checks (ST), conditional. 

Condition predicate: the Order Filler should value this field with a "P" when it wants to 
1335 inform the Order Result Tracker of restricted access on the observations and reports to 
privileged users. 

6.6 Acknowledgement of OUL and ORU messages 

OUL and ORU messages received by the Order Result Tracker shall generate a logical 
acknowledgement message from the Order Result Tracker to the Order Filler. This General 
1340 Acknowledgement Message ‘ACK’ shall be built according to HL7 V2.5 standard. 
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7 Transaction PAT-4: Procedure Scheduled and Update 

This transaction is very similar to the RAD-4 and RAD-13 transaction of the Radiology 
Technical Framework. The main differences are: 

1345 • PAT-4 combines the scheduling and the update of a procedure in one transaction; 

• PAT-4 uses OML messages instead of ORM messages. 

• PAT-4 handles specimen information. 

IHE implementers can refer to the Radiology Technical Framework for miscellaneous 
information. 

1350 7.1 Scope 

This transaction specifies a message from the Order Filler to the Image Manager notifying 
them that a procedure has been scheduled. This transaction also involves changes to 
procedure information communicated from the Order Filler to the Image Manager. 

Scheduling does not necessarily mean precise time assignment for the particular procedures. 
1355 However, the Order Filler shall handle all orders in such a way that it is capable of informing 
the Image about procedure timing and resources used to perform a procedure. 

This message serves as a trigger event for the Image Manager, informing it to obtain 
necessary information and apply rules to ensure the availability of relevant information to the 
technician. The Image Manager may need the information to create the Requested Procedure 
1360 context for its purposes. The Procedure Scheduled transaction includes the initial scheduling 
message. 

The Order Filler will need to communicate with multiple Image Managers. The Order Filler 
shall broadcast these scheduling messages to all Image Managers. An Image Manager shall be 
able to receive and process these messages with the understanding that the images and MPPS 
1365 events for these procedures may be sent to a different Image Manager. 

Unlike the order OML message sent between the Order Placer and Order Filler, the OML 
message from the Order Filler and Image Manager may reference a previously scheduled 
Requested Procedure identified by a Study Instance UID. 

7.2 Use Case Roles 

1370 



1375 
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Actor: Order Filler 

Role: Enters, modifies and stores information about patients, receives orders, schedules 
Procedures (exams), modifies information about them (rescheduling, cancellations, code 
1380 changes, etc.). 

Actor: Image Manager 

Role: Receives information about Patients, Orders, and schedules, and uses this information 
to assist in image management. 


1385 


1390 


7.3 Referenced standards 

HL7 version 2.5: 

• Chapter 2: "Control" — > generic segments and data types 

• Chapter 3: "ADT" —> PID and PV1 segments 

• Chapter 4: "Order Entry" — > OML and ORL messages 

• Chapter 7: "Observation Reporting" —> SPM segment 

• Chapter 13: "Clinical Pathology Automation" —> SAC segment 


7.4 Interaction diagrams 

Since Pathology request can involve several specimens and a specimen may be divided in 
several pieces that need to be clearly identified and transported in distinct containers, the most 
appropriate message for Pathology procedures is the 0ML A 021 message. This message is a 
1395 battery-centric structure. It contains: 

• a list of ordered batteries/procedure; 

• a list of specimens underneath each battery/procedure; 

• a list of containers underneath each specimen. 

Observation result segments may be added after each battery/procedure for providing the 
1400 Order Filler with all additional details that are necessary for performing the fulfilling the 
order. 

In all interaction diagrams below, the initiator transmits an 0ML A 021 message, the responder 
SHALL respond with an Application acknowledgement message 0RL A 022. 
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7.4.1 Normal process of a procedure 


The figure below shows the flow of messages in the normal process of a procedure, from 
creating of the procedure by the Order Filler, to the "procedure completed" event notified by 
the Image Manager. 


Order Filler 


Image 



Manager 


Schedules a new 
procedure 

^ OML A Q21, ORC-1 = 


: NW 


□ Changes the procedure (add 
parts, slides ...) 

0ML A 021, ORC-1 =XO 


0RL A 022 (application acknowledgement) 


0RL A 022 (application acknowledgement) 


Figure 7-1: Normal process of a procedure. 
7.4.2 Cancellation of a procedure by the Order Filler 


Order Filler 


Image 



Manager 


□ 


Cancels a procedure 


0ML A 021, ORC-1 =CA 


0RL A 022, ORC-1 = CR (cancel as requested) 


or ORC-1 =UC (unable to cancel) 


D 


The cancel request is 
accepted or refused (if 
the processing has 
already started) 


Figure 7-2: Cancellation of procedure. 

7.5 Messages static definitions 

7.5.1 0ML A 021 - static definition 

The Order Filler uses an 0ML A 021 message to convey necessary procedure information. The 
Procedure Scheduled and Updated Transaction will perform the additional task of providing 
Patient Demographic information to the Image Manager. The Image Manager shall obtain the 
Patient Demographic information from the 0ML A 021 message, specifically the PID and PV1 
segments. For this reason, the Order Filler must complete these segments. 

The Order Filler uses the OML message in a context different from the context existing 
between Order Placer and Order Filler. The Order Filler shall send as many OML messages as 
there are Requested Procedures identified to fill a single order. Each OML message shall 
contain as many ORC/OBR pairs as there are Protocol Codes in all Scheduled Procedure 
Steps for that Requested Procedure. 

It is actually common for the Order Filler to receive a single OML from the Order Placer 
system, but choose to expand that order into multiple Requested Procedures, therefore 
sending multiple OMLs to the Image Manager. Taking this into account, the Order Tiller will 
consider itself an “order placer” in relation to the Image Manager. 
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Table 7-1: OML A Q21 message description for PAT-4. 


Segment 

Meaning 

Usage 

Card. 

HL7 chapter 

MSH 

Message Header 

R 

[1-1] 

2 

[ 

— PATIENT begin 

RE 

[0..1] 


PID 

Patient Identification 

R 

[1-1] 

3 

[ pvi ] 

Patient Visit 

RE 

[0..1] 

3 

] 

— PATIENT end 




{ 

— ORDER begin 

R 

[1..*] 


ORC 

Common Order (for one battery) 

R 

[1-1] 

4 

[TQ1] 

Timing Quantity 

RE 

[0..1] 

4 


— OBSERVATION REQUEST begin 

R 

[1-1] 


OBR 

Observation Request 

R 

[1-1] 

4 

{ [NTE] } 

Notes and Comments 

O 

[0..*] 

2 

[{ 

— OBSERVATION begin 

O 

[0..*] 


OBX 

Observation Result 

R 

[1-1] 

7 

[ {NTE} ] 

Comment of the result 

C 

[0..*] 

2 

}] 

— OBSERVATION end 




[{ 

— SPECIMEN begin 

O 

[0..*] 


SPM 

Specimen 

R 

[1—1] 

7 

[{SAC}] 

Container 

C 

[2..*] 

13 

}] 

— SPECIMEN end 





— OBSERVATION REQUEST end 




} 

— ORDER end 




ZDS 

Additional identification information 

R 

[1-1] 



Field MSH-9 - Message Type (MSG) shall have its three components respectively valued to 
“OML”, “021” and “0ML_021”. 

The triplet (ORC, TQ1, OBR) represents the order (i.e. an ordered battery/test). This triplet is 
1435 repeated as many times as the number of batteries/procedure contained in the order group. 

The OBSERVATION (OBX) repeatable segment group carries the observations provided by 
the order placer. 

Condition predicate for the SAC segment: See the common definition of the SAC segment in 
section 3.10. 

1440 The ZDS segment is specific to IHE. It contains additional identification information such as 
the Study Instance UID. 

7.5.2 0RL A 022 static definition 

The static definition of this message is already described in paragraph 4.5.3. 

7.5.3 Specific segments description for transaction PAT-4 

1445 7.5.3.1 ORC - Common Order segment 


Rev 1.14 for Trial Implementation 
Publication 25/01/2008 


53/82 


Copyright © IHE-International 




IHE PAT Technical framework, vol.2 (PAT TF-2): Integration profiles 


HL7 v2.5: chapter 4 (4.5.3) 

ORC-1 Order Control (ID), required. This field may be considered the "trigger event" 
identifier for orders. Many order control codes are defined in the HL7 table 0119 - Order 
Control Codes. For transaction PAT-4, the IHE Pathology Technical Framework allows only 
1450 the following subset: 


Table 7-2: Supported order control codes for PAT-4. 


Value 

Description of use 

NW 

“New Order”. 

OK 

“Notification or request accepted”. Event notification in OML message. Event 
acknowledgement in ORL message. 

XO 

“Change order/service request”. 

CA 

“Cancel order/ service request”. 

CR 

“Canceled as requested”. Event acknowledgement in ORL message responding to 

OML (CA) 

UC 

“Unable to cancel”. Event acknowledgement in ORL message responding to OML 
(CA) 


7.5.3.2 ZDS - Observation/Result segment 


IHE Radiology Technical Framework: vol 2 (4.4.4.1.2.5). 


Table 7-3: ZDS - ZDS segment. 


SEQ 

LEN 

DT 

Usage 

Card. 

TBL# 

ITEM# 

Element name 

1 

200 

RP 

R 

[1-1] 


Z0001 

Study Instance UID 


1455 Components of the Study Instance UID field shall be encoded as given in the following table. 


Table 7-4: ZDS segmenl 

t Study Instance UID description. 

Component Number 

Component Name 

Shall Contain: 

1 

Reference Pointer 

DICOM compliant Study Instance UID value 

2 

Application ID 

Implementation specific 

3 

Type of Data 

“Application” 

4 

Subtype 

“DICOM” 


7.5.4 Expected Actions 

The Image Manager is expected to perform the following actions based on the value of the 
field ORC-1 Order Control Code: 

1460 CA - Procedure has been cancelled, usually due to the cancellation of the underlying order; 
the Image Manager shall inactivate corresponding procedure information using Study 
Instance UID as a unique key of the Requested Procedure in question. Information from PID 
and PV1 segments shall not be used to update patient or visit information. 

XO - Procedure-related information (including scheduled date/time and/or resource) has been 
1465 changed. The Image Manager shall modify corresponding procedure information using the 
Study Instance UID as a unique key of the procedure in question. Information from PID and 
PV 1 segments shall not be used to update patient or visit information. 
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8 Transaction PAT-5 - Query Modality Worklist 

1470 This section corresponds to Transaction PAT-5 of the IHE Technical Framework. Transaction 
PAT-5 is used by the Order Filler and Acquisition Modalities. 

It is essentially based on similar transaction RAD-5 designed for Radiology. The main 
addition in PAT-5 is the introduction of the Specimen Identification which is required to 
unambiguously identify the objects of the reed world (i.e. a physical object [part, tissue 
1475 samples, tissue section, smears, etc]) subject of the imaging procedure. By convention, a 
specimen in DICOM is identified by its container identifier when there is only one specimen 
in the container. 

8.1 Scope 

This transaction takes place at the Acquisition Modality at the point of scan/acquisition by a 
personal of the pathology department or office. When a patient set of specimen(s) is received 
for the scheduled procedure, the personal performing the procedure must examine key 
information elements as they relate to the procedure, the correctness of the procedure that has 
been ordered, and comments that may have been entered by the referring physician and/or 
pathologist, among others. The procedure will be mostly scheduled only at the reception of 
the specimen. The personal at the Acquisition Modality uses the DICOM Modality Worklist 
(MWF) to query the Order Filler for Scheduled Procedure Steps which correspond to the 
necessary image acquisitions. The list is downloaded to the Acquisition Modality and the 
personal verifies the information on the Acquisition Modality console. In the Modality 
Images Stored transaction this information will be included in the header of the generated 
images (See Appendix B). 

8.2 Use Case Roles 



Actor: Acquisition Modality 

1495 Role: Responsible for requesting and receiving data from the Order Filler, with the ability to 
validate the data and correct some discrepancies. 

Actor: Order Filler 

Role: Responsible for accepting requests for MWF from an acquisition modality, performing 
the query, and sending the response back.. 

1500 8.3 Referenced Standards 

DICOM 2003 PS 3.4: Modality Worklist SOP Class 

Supplement 122: Specimen Identification and Revised Pathology SOP Classes 


1480 


1485 


1490 
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Revision: 12 - 2007/05/05 


1505 


8.4 Interaction Diagrams 


Acquisition 

Modality 

■ 


Order Filler 


■ 

1 


Query Scheduled MWL 

■ 

■ 

■ 

- 


Receive Scheduled MWL 


Figure 8-1: Interaction diagram of the PAT-5 transaction. 

8.5 Query Scheduled MWL Message 

This is the Worklist query message sent to the Order Filler. 

1510 8.5.1 Trigger Events 

The specimen arrives at the Acquisition Modality for a procedure. 

8.5.2 Message Semantics 

The Acquisition Modality uses the C-FIND Request of the DICOM Modality Worklist SOP 
Class to query for the worklist from the DS S/Order Filler. The Acquisition Modality performs 
1515 the SCU role and the Order Filler the SCP role. 

Acquisition Modalities shall support individually each one of the required query keys listed in 
Table 6.3 - Matching and Return Keys for Modality Worklist. In addition, at least one of the 
following two combinations of keys shall be supported by the Acquisition Modality: 

1. The Patient Based Query: query for a worklist specific for a particular patient or a 
1520 particular specimen. The SCU shall support all (15) combinations of the matching key 

attributes listed in table 1.5-1 by including 1 or more keys. 


Table 8-1: MWL keys for Query by Patient. 


Matching Key Attributes 

Tag 

Patient's Name 

(0010,0010) 

Patient ID 

(0010,0020) 

Accession Number 

(0008,0050) 

Requested Procedure ID 

(0040,1001) 

Specimen Container Identifier 

(0040,x512) 

Specimen Identifier 

(0040, x551) 


1525 2. The Broad Query: query for a broad worklist, based on the scheduled procedures. 

The schedule of the procedure has been either done when the specimen has been sent 
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by the prescriber, or done when it has been received by the pathology facility. The 
SCU shall support all (7) combinations of the matching key attributes listed in table 
4.5-2 by including 1 or more keys. 

1530 Table 8-2: MWL keys for the board worklist queries. 


Matching Key Attributes 

Tag 

Scheduled Procedure Step Start Date 

(0040,0002) 

Modality 

(0008,0060) 

Scheduled Station AE-Title 

(0040,0001) 


8.5.2.1 Examples for the Use of Matching Key Attributes 

• Using the Scheduled Procedure Step Start Date: query for all the procedures in my 
department that are scheduled for the start date specified. 

• Using the Modality key: query for all the procedures that are scheduled on this type of 
1535 modality (e.g., all GM, SM, XC exams). 

• Using AE Title key: query for all the procedures that are scheduled on the modality with 
the specified AE Title. 

• Using the Scheduled Procedure Step Start Date and Modality keys: query for all the VL 
(GM, SM, XC) procedures that are scheduled for today 

1540 Note 1: D1COM defines that dates and times are matched by their meaning, not as literal 
strings. If an application is concerned about how a single value matching of dates and times 
is performed by another application, it may consider using range matching instead (e.g. 
"<today>-<today>"), which is always performed by meaning. 

Note 2: Applications are recommended to append a wildcard if one was not previously 
1545 entered by the user, at the end of each component of the structured Patient Name. 

8.5.2.2 Matching Keys and Return Keys for Display 

The Modality (GM, SM, XC) is required to query for specific attributes (return keys) that will 
be inserted into the image objects. The requirements for the attributes in the stored images are 
defined in sec. Appendix B. There are additional attributes that may be queried for use on the 
1550 Acquisition Modality but might not be inserted into the composite image object. 
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Table 8-3 summarizes the matching key requirements and lists the optional and required 
attributes that may be requested and is expected to be returned in order to make these 
available to the user at the Acquisition Modality. All display requirements are an addition to 
the DICOM Standard requirements for the Modality Worklist SOP Class. 

1555 
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Table 8-3: Return and matching keys for modality worklist. 


Attribute Name 

Tag 

Query Keys 
Matching 

Query Keys 
Return 



SCU 

SCP 

SCU 

SCP 

Scheduled Procedure Step 

Scheduled Procedure Step Sequence 

(0040,0100) 



[IHE-1 ] 

[IHE-2] 

>Scheduled Station AE Title 

(0040,0001) 

R+ 

R 

R+* 

R 

>Scheduled Procedure Step Start 
Date 

(0040,0002) 

R+ 

R 

R+ 

R 

>Scheduled Procedure Step Start 
Time 

(0040,0003) 

O 

R 

R+ 

R 

> Scheduled Procedure Step Location 

(0040,0011) 

O 

O 

O 

O 

>Modality 

(0008,0060) 

R+ 

R 

R+ 

R 

>Scheduled Performing Physician's 
Name 

(0040,0006) 

O 

R 

O 

R 

>Scheduled Procedure Step ID 

(0040,0009) 

O 

O 

R+* 

R 

>Scheduled Protocol Code Sequence 

(0040,0008) 

»Code Value 

(0008,0100) 

o 

O 

R+* 

R 

»Coding Scheme Version 

(0008,0103) 

o 

O 

O 

O 

»Coding Scheme Designator 

(0008,0102) 

o 

O 

R+* 

R 

»Code Meaning 

(0008,0104) 

o 

O 

R+ 

R+ 

>Scheduled Procedure Step 

Description 

(0040,0007) 

o 

O 

R+ 

R 


Scheduled Specimen Sequence 

(0040, x500) 

[IHE-4] 

>Specimen Container Identifier 

(0040,x512) 

O 

R+ 

R+* 

R+ 

>Specimen Container Type Code 
Sequence 

(0040,x518) 

[IHE-5] 

»Code Value 

(0008,0100) 

O 

O 

R+* 

R+ 

»Coding Scheme Designator 

(0008,0102) 

O 

O 

R+* 

R+ 

»Coding Scheme Version 

(0008,0103) 

O 

O 

O 

O 

»Code Meaning 

(0008,0104) 

O 

O 

R+ 

R+ 

>Specimen Sequence 

(0040,0550) 

[IHE-6] 

»Specimen Identifier 

(0040,0551) 

O 

O 

R+* 

R+ 

»Specimen UID 

(0040,x554) 

O 

o 

R+* 

R+ 


Requested Procedure 

Requested Procedure Comments 

(0040,1400) 

o 

0 

0 

O 

Requested Procedure Description 

(0032,1060) 

o 

0 

R+ 

R 

Requested Procedure Code Sequence 

(0032,1064) 

>Code Value 

(0008,0100) 

o 

0 

R+* 

R 

>Coding Scheme Version 

(0008,0103) 

o 

0 

O 

O 

>Coding Scheme Designator 

(0008,0102) 

o 

0 

R+* 

R 

>Code Meaning 

(0008,0104) 

o 

0 

R+ 

R+ 
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Attribute Name 

Tag 

Query Keys 
Matching 

Query Keys 
Return 



SCU 

SCP 

SCU 

SCP 

Requested Procedure ID 

(0040,1001) 

R+ 

(Note 1) 

R+ 

(Note 1) 

R+ 

R 

Names of Intended recipients of 
results 

(0040,1010) 

O 

O 

O 

o 

Study Instance UID 

(0020,000D) 

O 

O 

R+* 

R 

Referenced Study Sequence 

(0008,1110) 

>Referenced SOP Class UID 

(0008,1150) 

o 

0 

R+* 

R 

[IHE-3] 

>Referenced SOP Instance UID 

(0008,1155) 

o 

0 

R+* 

R 

[IHE-3] 

Imaging Service Request 

Imaging Service Request Comments 

(0040,2400) 

0 

0 

O 

O 

Accession Number 

(0008,0050) 

R+ 

(Note 1) 

R+ 

(Note 1) 

R+ 

R+ 

Requesting Physician 

(0032,1032) 

O 

O 

O 

R 

Requesting Service 

(0032,1033) 

R+ 

R+ 

R+ 

R+ 

Referring Physician's Name 

(0008,0090) 

O 

O 

R+ 

R 

Admission ID 

(0038,00100 

O 

O 

O 

R 

Visit Status 

Current Patient Location 

(0038,0300) 

O 

O 

O 

R 

Visit Relationship 

Referenced Patient Sequence 

(0008,1120) 

>Referenced SOP Class UID 

(0008,1150) 

O 

O 

O 

R 

>Referenced SOP Instance UID 

(0008,1155) 

O 

O 

O 

R 

Patient Identification 

Patient's Name 

(0010,0010) 

R+ 

R 

R+ 

R 

Patient ID 

(0010,0020) 

R+ 

R 

R+ 

R 

Other Patient ID’s 

(0010,1000) 

O 

O 

O 

O 

Patient Demographic 

Patients Birth Date 

(0010,0030) 

O 

O 

R+ 

R 

Patient's Sex 

(0010,0040) 

O 

O 

R+ 

R 

Confidentiality constraint on patient 
data 

(0040,3001) 

O 

O 

O 

R 

Ethnic Group [IHE-7] 

(0010,2160) 

O 

O 

O 

O 

Patient Comment 

(0010,4000) 

O 

O 

O 

O 

Patient Medical 

Patient State 

(0038,0500) 

O 

O 

O 

R 

Pregnancy Status 

(0010,21C0) 

O 

O 

O 

R 

Medical Alerts 

(0010,2000) 

O 

O 

O 

R 

Additional Patient History 

(0010,21B0) 

O 

O 

O 

O 

Contrast Allergies 

(0010,2110) 

O 

O 

O 

R 

Patient Weight 

(0010,1030) 

O 

O 

O 

R 

Special Needs 

(0038,0050) 

O 

O 

O 

R 
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Note 1: The matching performed by the SCP for the Requested Procedure ID and Accession 
Number attributes shall be single value (SV) matching. 

(IHE-1): SCU implementations may choose to obtain the values contained in attributes that 
1560 are part of the Scheduled Procedure Step sequence in either one of three ways. The first one is 
to request a universal match on the sequence attribute (zero length attribute). The second one 
is a universal sequence match (zero length item) for all attributes of the Scheduled Procedure 
Step sequence. The third one is to request a universal attribute match for selected attributes 
contained in the Scheduled Procedure Step sequence. 

1565 (IHE-2): SCP implementations shall support, per the DICOM Standard, three ways to let the 

Query SCU obtain the values contained in attributes that are part of the Scheduled Procedure 
Step sequence. The first one is to support a universal match on the sequence attribute (zero 
length attribute), and all managed attributes will be returned. The second one is to support a 
universal sequence match (zero length item) for all attributes of the Scheduled Procedure Step 
1570 sequence, and all managed attributes will be returned. The third one is to support a universal 
attribute match for selected attributes contained in the Scheduled Procedure Step sequence, 
and the managed attributes that were selected will be returned. 

(IHE-3): In the Query Modality Worklist provided by an Order Filler, the Referenced Study 
Sequence shall contain only one item. Furthermore, the Referenced SOP Instance UID 
1575 contained in the Referenced Study Sequence shall contain the same UID value as the Study 
Instance UID for a Requested Procedure. This UID value is also conveyed to the Image 
Manager in the Study UID field of the Procedure Scheduled transaction. 

(IHE-4): One or more Items may be returned in this Sequence. 

(IHE-5): Only one Item shall be returned in this Sequence. The coded section refinning the 
1580 specimen identification are detailed in the Sup. 22. 

(IHE-6): Zero or more Items may be returned in this Sequence. 

(IHE-7): This field is presented as optional, but depending of the regulations, it may be either 
forbidden (e.g. European Union), or required (e.g. USA), or optional. 

1585 Specimen container and specimen code sequence identification and description are described 

in the DICOM supp 122 DICOM code definitions table. 

8.5.3 Expected Actions 

The Order Filler performs the query and sends the DICOM Modality Worklist to the 
Acquisition Modality. 

1590 8.6 Receive Scheduled MWL Message 

This is the message that the Order Filler sends to the modality as a reply containing DICOM 
Modality Worklist information. 

8.6.1 Trigger Events 

The Order Filler had received a query for a MWF. 

1595 8.6.2 Message Semantics 

C-FIND Response from the DICOM Modality Worklist SOP Class will be used for this 
message. Some of the attributes queried through the MWF SOP class originate with the Order 
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Placer, while other attributes are managed internally by the Order Filler. The Order Filler will 
determine the Requested Procedures needed to fulfill the Order, and decompose the 
1600 Requested Procedures in Scheduled Procedure Steps, assigning proper Protocol Codes. The 
DS S/Order Filler shall support the definition of multiple Protocol Codes in a Scheduled 
Protocol Code Sequence contained in the Scheduled Procedure Steps for any Requested 
Procedure. Coded Values shall be used to specify exactly what actions are to be performed at 
the Acquisition Modality. In addition to these Coded Values additional instructions for the 
1605 technologist may be specified. It is recommended to use the Scheduled Procedure Step 
Description and the Requested Procedure Description attributes for these additional specific 
instructions. 

Appendix C defines the origin and mappings of the attributes returned in a MWL query. 

The details of the C-FIND Response from the DICOM MWL SOP Class are depicted in the 
1610 previous tables and appendix B. At the time images are being created/generated, these 
attributes will be stored into the DICOM image instance headers. The Acquisition Modality 
may need additional information; however this is beyond the scope of this document. Refer to 
RAD TF-1, Appendix A for a discussion of Accession Number and Procedure ID. 

An Order may be cancelled after the corresponding Requested Procedure(s) and Scheduled 
1615 Procedure Steps have been scheduled, and possibly even after a Performed Procedure Step 
has been started. In this case the Order Filler shall remove the Scheduled Procedure Steps of 
the Order from its worklist, and the absence of these Scheduled Procedure Steps in the next 
C-FIND response to the Acquisition Modality will indicate that the procedure has been 
cancelled. In this way the technologist recognizes that the previously scheduled steps no 
1620 longer need to be performed. 

It is the responsibility of the Order Filler to ensure that the patient and procedure information 
is current in the Modality Worklist response. The Order Filler receives patient and procedure 
updates through Transactions PAT-1, PAT-2 and RAD-12. 

8.6.3 Expected Actions 

1625 The technologist checks for the existence of the Scheduled Procedure Steps, validates the 
displayed patient and procedure information, and checks the given instructions. 
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1630 


1635 


1640 


1645 


1650 


A: Attribute Consistency between Modality Worklist, 

Composite lODs and Evidence Documents 

This appendix is an integral part of the Pathology IHE Technical Framework. It reflects IHE’s 
adoption of DICOM-defined attribute consistency (Annex J, PS.3.17, since DICOM 2006; 
before: Annex M, PS3.4). It includes four sections: 

• The first section contains the IHE clarifications, additions and a summary of DICOM, 
PS.3.17, Annex J that relate to image acquisition. IHE requires that Modality Actors 
support the Attribute mapping defined in this table as they implement MWL and 
various IOD Storage SOP Classes for Transactions PAT-3 and RAD-8. IHE restates or 
extends some of the DICOM requirements as well as select some of the choices 
offered or enforce some of the recommendations of DICOM. A few additional IHE 
recommendations are also specified. 

• The second section defines attribute mappings for consistency in DICOM SR-based 
evidence objects generated by the Evidence Creator and Acquisition Modality. The 
DICOM SR objects are created based on existing images that provide values to be 
filled into the new evidence documents. 

• The third section defines additional IHE requirements for consistency of DICOM C- 
F1ND Return Key Attributes. 

• The fourth section introduces a real-world data model of the entities and their 
Attributes related to consistency. Readers are advised to use this data model along 
with the information presented in PAT TF-1: Appendices A to D. This data model is 
provided only for ease of understanding and does not introduce any additional IHE 
requirements. 


A.1: Image Acquisition Integration-critical Attributes 

The tables below describe requirements, recommendations or explanations on integration- 
critical attributes for image acquisition cases. They define which integration-critical attributes 
1655 need to be equal (copied or generated locally), in order to correctly relate scheduled and 
performed procedure steps for the use cases described in PAT TF-1: 4. 

General table structure: 

• The 1 st column denotes the DICOM attributes whose values shall be mapped between 
the DICOM objects (equal values in the same table row). The DICOM attribute tag is 
indicated for clarity. 

• The 2 nd to 4 th columns define where attribute values come from: all defined attribute 
values of one table row are equal. 

These columns read left to right: MWL return values (2 nd column), if existing, shall be 
used as the source for copies to Image/ Standalone IODs. 

• The MWL column is omitted if the described case does not include any MWL return 
values, or to simplify the table. 

Cell content conventions: 

• “Source” in a table cell means that the DICOM object defined in the table column 
(e.g. MWL) and created by one actor shall be the source of this value for the DICOM 

1670 attribute for another actor to fill in this value for their own objects (e.g. Image). 


1660 


1665 
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1675 


1680 


1685 


1690 


1695 


• “Copy” in a table cell means that the value shall be copied from a corresponding 
source attribute of another DICOM object, as defined by the table column. 

• ’’Copy from: <DICOM attributed’ means that, instead of using the DICOM 
attribute of the same row as the source, the source as specified in the referenced 
DICOM attribute shall be used. 

• “Equal” in a table cell means that an actor already knows the value, e.g. from some 
previously performed action. Thus, the circumstances of value generation do not 
matter. 

• “Equal (internally generated)” in a table cell means that an actor has internally 
generated a value that may be used in more than one DICOM object, without having 
obtained this value from another actor (i.e. no copy). 

• “Equal (copied from MWL)” in a table cell means that the actor shall use a value that 
it already knows from an MWL query result obtained for the same SPS in the append 
case. 

• ”Source-l”, “Copy-1 ” or “Equal-1” etc. are corresponding mapping attribute values, 
if several sources appear in one table row. 

• “See (IHE-X)” in a table cell denotes additional requirements, recommendations or 
explanations for the attribute value, as described in the table’s note “(IHE-X)”. 
Otherwise, brief text that fits into a table cell is presented in the cell. 

• “n.a.” in a table cell means that such an attribute or value shall not exist. Either the 
attribute is not defined by the DICOM standard for this object, or the particular 
sequence attribute is a DICOM type 3 attribute, and DICOM requires at least one 
sequence item to be present. 

Actor behavior: 

• An attribute from the column “Modality Worklist” shall be requested by a MWL SCU 
(Acquisition Modality) as a return key in its C-FIND Requests. The Order Filler shall 
return attribute values in the Modality Worklist C-FIND response (for a complete 
description, see 
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1700 • The MWL return attribute values, if available as a source, shall be used by the 

Acquisition Modality in filling the attribute shown on the corresponding rows both for 
Composite Instances and MPPS Instances. 

• If the MWL value is not existing (“n.a.”), then the Modality shall generate certain 
values internally. 

1705 
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Table A.l-1: Simple Case - required mapping of corresponding attributes. 

In the simple normal case, a Procedure Step is performed 
• exactly as scheduled, or 

1710 • different than scheduled, but without being rescheduled. 


DICOM attribute 

Modality Worklist 

(return attribute 
values) 

Image/ Standalone IOD 

Study Instance UID 

(0020.000D) 

Source 

Copy 

Referenced Study 
Sequence (0008,1110) 

Source 

Copy 

Accession number 

(0008,0050) 

Source 

Copy 

See (IHE-B.1.1) 

Requested Procedure 

ID (0040,1001) 

Source 

Request Attributes Sequence 

(0040,0275) 

Copy 

Requested Procedure 
Description 

(0032,1060) 

Source 

Copy 

Note: 

extended 

attribute 

Scheduled Procedure 
Step ID (0040,0009) 

Source 

Copy 

Scheduled Procedure 
Step Description 

(0040,0007) 

Source 

Copy 

Scheduled Protocol 
Code Sequence 

(0040,0008) 

Source 

Copy 

Performed Protocol 
Code Sequence 

(0040,0260) 

n.a. 

Equal (internally 

generated). 

Recommendation: 

Absent if the value is not 
known. 

Study ID (0020,0010) 

n.a. 

Equal (internally 
generated). 

Recommendation: use 
Requested Procedure ID. 

Performed Procedure 
Step ID (0040,0253) 

n.a. 

Equal (internally 
generated). 

See (IHE-B.1.2) 

Performed Procedure 
Step Start Date 

(0040,0244) 

n.a. 

Equal (internally 
generated). 

Recommendation: use 
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DICOM attribute 

Modality Worklist 

(return attribute 
values) 

Image/ Standalone IOD 



the same value for Study 
Date. 

Performed Procedure 
Step Start Time 

(0040,0245) 

n.a. 

Equal (internally 
generated). 

Recommendation: use 
the same value for Study 
Time. 

Performed Procedure 
Step Description 

(0040,0254) 

n.a. 

Equal (internally 
generated). 

Recommendation: use 
the same value for Study 
Description. 

Requested Procedure 
Code Sequence 

(0032,1064) 

Value shall be used 
for Procedure Code 
Sequence as 
specified below. 

n.a. 

Procedure Code 
Sequence (0008,1032) 

n.a. 

Copy from: Requested 
Procedure Code 

Sequence (0032,1064).- 
Recommendation: 
absent, if empty in 

MWL or performed 
acquisition is different to 
what was scheduled. 

Referenced SOP 

Class UID 
(0008,1150) 

n.a. 

^ 1.2.840.10 

g 008.3.1.2. 

s 3.3 

Referenced SOP 
Instance UID 

(0008,1155) 

n.a. 

& Equal to 

£ SOP 

Instance 
'g of the 

g associated 

g MPPS. 

£ See (IHE- 

B.1.3) 

Protocol Name 

(0018,1030) 

n.a. 

Recommendation: equal 
(internally generated) 


(IHE-B.1.1) A Zero Length Accession Number (One of the options proposed by DICOM 
PS3.17 Annex J) shall be created when no reliable value for this attribute is available. 
Reliable values are those that can be conveyed by means other than manual data entry such as 
a value received from the Order Filler via a Modality Worklist including an Accession 
1715 Number or received through a bar code reader. 
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(IHE-B.1.2) Performed Procedure Step ID is generated by the modality arbitrarily and is not 
necessarily unique: Two different Performed Procedure Steps may share the same ID (e.g. 
may have been generated by different modalities). This ID may not enable a receiving system 
to reliably relate the PPS to the associated Requested Procedure and SPS. It is not reliable to 
1720 assume that two PPSs with the same PPS ID value fulfill the same SPS/Requested Procedure, 
without checking the content of Scheduled Attributes Step Sequence. 

(IHE-B.1.3) In MPPS, SOP Instance UID is sent in the Affected SOP Instance UID 
(0000,1000) of the PPS N-Create message and in Requested SOP Instance UID (0000,1001) 
for the PPS N-Set message. SOP Instance UID (0008,0018) shall not be used. 

1725 

Table A.l-2: Append to a Simple/ Normal Case - required mapping of corresponding 

attributes. 

Similar to the simple case, the first PPS is generated in response to an SPS. Other PPSes are 
added at a later time, for instance due to unacceptable quality of certain images. 


DICOM attribute 

Filling values for: 

Original Image/ 
Standalone IOD 

Append Image/ Stand¬ 
alone IOD 

Study Instance UID 

(0020.000D) 

Equal (copied from 
MWL) 

Equal (copied from 
MWL) 

Referenced Study 
Sequence (0008,1110) 

Equal (copied from 
MWL) 

Equal (copied from 
MWL) 

Accession number 

(0008,0050) 

Equal (copied from 
MWL). See (IHE- 
B.2.1). 

Equal (copied from 
MWL). See (IHE- 
B.2.1). 

Requested Procedure 

ID (0040,1001) 

Request Attributes Sequence 

(0040,0275) 

Equal 
(copied 
from MWL) 

Request Attributes Sequence 

(0040,0275) 

Equal 

(copied 

from 

MWL) 

Requested Procedure 
Description 

(0032,1060) 

Equal 
(copied 
from MWL) 

Equal 

(copied 

from 

MWL) 

Scheduled Procedure 
Step ID (0040,0009) 

Equal 
(copied 
from MWL) 

Equal 

(copied 

from 

MWL) 

Scheduled Procedure 
Step Description 

(0040,0007) 

Equal 
(copied 
from MWL) 

Equal 

(copied 

from 

MWL) 

Scheduled Protocol 
Code Sequence 

(0040,0008) 

Equal 
(copied 
from MWL) 

Equal 

(copied 

from 

MWL) 

Performed Protocol 

Note: Values may 

Equal (internally 
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DICOM attribute 

Filling values for: 

Original Image/ 
Standalone IOD 

Append Image/ Stand¬ 
alone IOD 

Code Sequence 

(0040,0260) 

not be relevant for 
the appended image 
and associated 

MPPS, e.g. due to 
adding images from 
an adjacent body 
region or from doing 
measurements. 

generated). 
Recommendation: 
Absent if the value is 
not known. 

Study ID (0020,0010) 

Equal (internally 
generated) 
Recommendation: 
use Requested 
Procedure ID. 

Equal (internally 
generated) 

Recommendation: use 
Requested Procedure 
ID. 

Performed Procedure 
Step ID (0040,0253) 

Note: Values not 
relevant for the 
appended image and 
associated MPPS. 

Equal (internally 
generated). See (IHE- 
B.2.2) 

Performed Procedure 
Step Start Date 

(0040,0244) 

Note: Values not 
relevant for the 
appended image and 
associated MPPS. 

Equal (internally 
generated). See (IHE- 
B.2.3) 

Performed Procedure 
Step Start Time 

(0040,0245) 

Note: Values not 
relevant for the 
appended image and 
associated MPPS. 

Equal (internally 
generated). 

See (IHE-B.2.3) 

Performed Procedure 
Step Description 

(0040,0254) 

Note: Values not 
relevant for the 
appended image and 
associated MPPS. 

Equal (internally 
generated). See (IHE- 
B.2.3) 

Requested Procedure 
Code Sequence 

(0032,1064) 

n.a. 

n.a. 

Procedure Code 
Sequence (0008,1032) 

Equal. 

Note: May be absent (see Table 

B.1-1) 

Equal. If absent in 
original image, shall 
be absent here. 
Recommendation: 
absent, if performed 
acquisition is different 
from the original 
image’s procedure. 

Referenced SOP 

Class UID 

(0008,1150) 

i " Note: 
u c /3 § c Values not 
a- £ relevant 

g i 1.2.840.1000 
■§ 1 l 8.3.1.2.3.3 

* § 


Rev 1.14 for Trial Implementation 
Publication 25/01/2008 


69/82 


Copyright © IHE-International 





IHE PAT Technical framework, vol.2 (PAT TF-2): Integration profiles 


DICOM attribute 

Filling values for: 

Original Image/ 
Standalone IOD 

Append Image/ Stand¬ 
alone IOD 

Referenced SOP 
Instance UID 

(0008,1155) 


for the 

appended 

image. 


Equal to 

SOP 

Instance of 
the 

associated 
MPPS 
when exists. 

Protocol Name 

(0018,1030) 

Note: Values not 
relevant for the 
appended image. 

Recommendation: 
equal (internally 
generated). 


1730 (IHE-B.2.1) A Zero Length Accession Number (One of the options proposed by DICOM 

PS3.17 Annex J) needs to be created when no reliable value for this attribute is available. 
Reliable values are those that can be conveyed by means other than manual data entry such as 
a value received from the Order Filler via a Modality Worklist including an Accession 
Number or received through a bar code reader. 

1735 (IHE-B.2.2) Performed Procedure Step ID is generated by the modality arbitrarily and is not 

necessarily unique: Two different Performed Procedure Steps may share the same ID (e.g. 
may have been generated by different modalities). This ID may not enable a receiving system 
to reliably relate the PPS to the associated Requested Procedure and SPS. It is not reliable to 
assume that two PPSs with the same PPS ID value fulfill the same SPS/Requested Procedure, 
1740 without checking the content of Scheduled Attributes Step Sequence. 

(IHE-B.2.3) In the Image IODs created in Append Case, the Study Date, Study Time and 
Study Description shall re-use the corresponding values from the original images to which 
they are appended. 

A.2: Evidence Documents Integration - critical Attributes 

1745 The table in this section is analogous to the tables in the previous section, where the 
Acquisition Modality uses certain attributes from the Modality Worklist in order to fill in 
related image values in a consistent manner. Similarly, the Evidence Creator or Acquisition 
Modality in the Evidence Documents Integration Profile, which do not get a Modality 
Worklist, use relevant data from images that originate from a scheduled acquisition as input 
1750 for consistently filling in corresponding values in DICOM SR Evidence Documents. 

Note: In the Pathology Scheduled Workflow Integration Profile, the Evidence Creator creates 
images. This case can be considered an image acquisition append case (see table B.l-2)._ 

General table structure: 

• The 1 st column denotes the DICOM attributes whose values shall be mapped between the 

1755 DICOM objects (equal values in the same table row). The DICOM attribute tag is 

indicated for clarity. 

• The 2nd and 3rd columns define for each attribute how the attribute values are filled for 
the different IODs. 
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These columns read left to right within the same row: Image/ Standalone IOD (2nd 
1760 column) shall be used as the source for copies to Evidence Documents (DICOM SR IOD). 

Cell content conventions: 

• These are the same as defined in the corresponding paragraph of B.l. 

Actor behavior: 

• The values from the Image/ Standalone IOD, if available as a source, shall be used by the 

1765 Evidence Creator or Acquisition Modality to fill in the attribute shown on the 

corresponding rows for Evidence Document instances. 

Table A.2-1: Evidence Document attribute mapping. 

This table defines how to use values from Image or Standalone IODs that were previously 
1770 generated by a different actor in order to fill in values into newly generated Evidence 
Documents created by an Evidence Creator or Acquisition Modality in the Evidence 
Documents Integration Profile. 

Note that this mapping table is most relevant for cases where evidence is created based on 
images that originate from a scheduled acquisition, otherwise most of the workflow 
1775 integration-critical attributes will be absent or empty in the originating Image/ Standalone 
IODs. 


DICOM attribute 

Image/ Standalone IOD 

Filling values for 

Evidence Documents 

Study Instance UID 

(0020,000D) 

Source 

Copy 

(IHE-B.2-1.1) 

Referenced Study 
Sequence (0008,1110) 

Source. 

(IHE-B.2-1.2) 

Copy, if not absent in Image/ 

Standalone IOD. 

(IHE-B. 2-1.1) 

Accession number 

(0008,0050) 

Source 

Copy 

(IHE-B. 2-1.1) 

Requested Procedure 

ID (0040,1001) 

Request Attributes 
Sequence 

(0040,0275) 

Source 
(IHE-B.2- 
1.2) 

Referenced Request 
Sequence 

(0040, A370) 

Copy, if not absent 
in Image/ Standalone 
IOD. 

Requested Procedure 
Description 

(0032,1060) 

Source 
(IHE-B.2- 
1.2) 

Copy, if not absent 
in Image/ Standalone 
IOD. 

Requested Procedure 
Code Sequence 

(0032,1064) 

Source 
(IHE-B.2- 
1.2) 

Copy, if not absent in 
Image/ Standalone 

IOD. 

Procedure Code 
Sequence (0008,1032) 

Source. 

Note: May be absent. 

Recommendation: 

Copy, if not absent in Image/ 

Standalone IOD. 


(IHE-B.2-1.1) If the creation of evidence relates to a Requested Procedure, it is required per 
DICOM to also fill this information in the Referenced Request Sequence (0040,A370). 


(IHE-B.2-1.2) May be absent in case of an unscheduled image acquisition. 
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1780 A.3: Context-critical Attributes 

This section extends the above table with additional IHE Requirements based on a number of 
context-critical attributes (Type 2 in DICOM) common to most images and standalone IODs 
when provided in response to a C-FIND Request in Return Key Attributes. The content of 
this table is strictly consistent with PS 3.17 Annex J of DICOM. 

1785 


Modality Worklist 

Images and Standalone IOD 

Patient Name 

Patient Name (note 1) 

Patient ID 

Patient ID (note 1) 

Patient’s Birth Date 

Patient’s Birth Date (note 2) 

Patient’s Sex 

Patient’s Sex (note 2) 

Referring Physician's Name 

Referring Physician's Name 
(note 2) 

Specimen ID 

Specimen ID 


Note 1: This Attribute may be zero length when the Order Filler/Order Filler providing the 
Modality Worklist service is not accessible. Pre-registered values for Patient ID and Patient 
Name will be used in the Unidentified Patient cases defined in the IHE Technical Framework. 

1790 Note 2: This Attribute may be zero length when the Order Filler/Order Filler providing 
Modality Worklist service is not accessible or the Attributes returned by MWL are zero 
length. 


1795 


1800 


1805 


1810 


A.4: Consistency Data Model 

The section introduces a data model of the entities and their Attributes related to Consistency. 
Readers are advised to use this data model along with the table presented in section 1 of this 
appendix. This data model is provided only for ease of understanding and does not introduce 
any additional IHE requirements. 

Entities are shown by solid line rectangular boxes. 


A relationship between two entities is shown by an arrow or a straight line. In the case of 
straight lines the Attributes used to define this relationship are not described by this model 
(they are generally well understood). In the case an arrow is used: 


• The attribute in the referencing entity used to define th is relationship is shown within 

in the Requested 


the entity in a box next to the origin of the arrow (e.g. Ref. St. Seq. 


Procedure Entity is used to link this entity with the Conceptual Study Management 
entity). 


The referenced attribute is shown at the tip of the arrow also in a rectangular box but 
with curly brackets (e.g. {Study Instance UID} ). In some cases the referencing 
Attribute has a different name than this referenced Attribute. This reflects the way 
DICOM has elected to name and or encode those Attributes. The number shown 
between square brackets is the Data Type as defined by DICOM. 


The cardinality of relationship is defined both along straight lines and arrows: 

• Cardinality of the relationship between the entities is shown along the arrow/lines. 
The direction of the arrow has no influence on the cardinality definition. This 


Rev 1.14 for Trial Implementation 
Publication 25/01/2008 


72/82 


Copyright © IHE-International 





IHE PAT Technical framework, vol.2 (PAT TF-2): Integration profiles 

cardinality reflects the cardinality between entities in a real-world data model (used as 
1815 defined by DICOM). This cardinality may be slightly different in the DICOM 

Information Object Definition data models as this data-model reflects entity 
relationship supported in the context of information communication. For example “I- 
Series to I-Composite” has a 1 to 0-n relationship to reflect that a PPS may contain a 
series with no Composite Instances (e.g. images). However in the context of the 
1820 DICOM Storage Service Class, a Series must contain at least one Composite Instance 

(e.g. image). In other terms series with no images cannot be stored but can be defined 
by DICOM Performed Procedure Steps. 

Arrows with thick lines reflect the fact that the referencing Attributes are UID (broad 
uniqueness), as opposed to simple IDs, which are shown by thin line arrows. 

1825 In this Data Model, two dotted-line boxes are shown: 

• The first one groups 4 entities: I-Patient, I-Study, I-Series, and I-Composite. This is 
intended to reflect the fact that Composite Instances are transferred (Storage Service 
Class) by grouping these four entities. These 4 entities are those defined by DICOM 
Composite Image Information Model (See PS 3.3, section A. 1.2) 

1830 • The second one groups 2 entities: Requested Procedure and Conceptual Study 

Management. This reflects that those two entities are always in a one-to-one 
relationship. The Requested Procedure entity as well as those associated with it 
(Patient, Imaging Service Request, Schedule Procedure Step and Performed Procedure 
Step) are defined by the DICOM Model of the Real World for the purpose of the 
1835 Modality-IS Interface (See PS3.3, section 7.3). The “Conceptual Study Management” 

entity is special in that its only attribute in the context of this version of the IHE 
Technical Framework is the Referenced SOP Instance UID (found in Reference Study 
Sequence). This Conceptual Study Detached Study entity (without the Detached 
Management Study SOP Class being used) is defined by DICOM in PS3.4 section 
1840 M.2. 
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m” when multiple Scheduled Procedure Steps are satisfied 
by one Performed Procedure Step. 


An Attribute which is a unique identifier (DICOM UID) or an identifier (DICOM ID) or for the entity 
An Attribute which is used in the entity to reference another entity as show by the associated arrow. 

The Attribute Type as defined by DICOM for this entity (IHE may strengthen this requirement) 

A relationship between two entities using a unique identifier (DICOM UID) 

A bidirectional relationship between two entities using a pair of unique identifiers (DICOM UID) 

A relationship between two entities using a simple identifier (DICOM ID) 

Cardinality of the relationship between the entitties, not the identifiers. (Direction of the arrow is irrelevant to cardinality.) 


Legend: 

{xxx} 

yyy 

[n] 



n-m 


1845 


Figure A-l. Data Consistency Model: Modality Worklist Information Model, Composite 
IODs and Modality Performed Procedure Step IOD. 
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B: HL7 Order Mapping to DICOM MWL 

This appendix defines the mapping of the HL7 ADT and OML messages to the DICOM 
Modality Worklist. Note that the HL7 messages address information regarding the order, not 
scheduling or resource management information. The scheduling and resource management is 
1850 internal to the Order Filler. 

Note also that this mapping does not apply to Procedure Scheduled Transaction (message 
from Order Scheduler to Image Manager). Also see the IHE ER Model and the HL7 
Implementation Notes in section 2 for a more thorough definition of field lengths, value 
representations, and attribute types. See paragraph Erreur ! Source du renvoi introuvable. 
1855 for the Procedure Scheduled and Update transaction description. 

Mappings between HL7 and DICOM are illustrated in the following manner: 

• Element Name (HL7 item_number.component #/ DICOM (group, element)) 

• The component value is not listed if the HL7 element does not contain multiple 
components. 

1860 Table B-l: HL7 Order mapping to DICOM MWL. 


DICOM Description / 
Module 

DICOM Tag 

DICOM 

SCP 

Matching 
Key Type 

DICOM 

SCP 

Return 

Key 

Type 

HL7 

Description 

HL7 Item 
# 

HL7 

Segment 

Notes 

SOP Common 

Specific Character 
Set 

(0008,0005) 

0 

1C 

Principal 

Language 

of 

Message 

00693 

OML 

MSH:18 


Scheduled Procedure Step 

Scheduled 

Procedure Step 
Sequence 

(0040,0100) 

R 

1 





>Scheduled station 
AE title 

(0040,0001) 

R 

1 




Generated by 
the Order 
Filler 

>Scheduled 
Procedure Step 

Start Date 

(0040,0002) 

R 

1 




Generated by 
the Order 
Filler 

>Scheduled 
Procedure Step 

Start Time 

(0040,0003) 

R 

1 




Generated by 
the Order 
Filler 

>Modality 

(0008,0060) 

R 

1 




Generated by 
the Order 
Filler (note 

3) 

>Scheduled 

Performing 

(0040,0006) 

R 

2 

Technician 

00266 

OML 

OBR:34 

See note 9 
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Physician's Name 








>Scheduled 
Procedure Step 
Description 

(0040,0007) 

0 

1C 




Generated by 
the Order 
Filler 

>Scheduled Station 
Name 

(0040,0010) 

0 

2 




Generated by 
the Order 
Filler 

>Scheduled 
Procedure Step 
Location 

(0040,0011) 

0 

2 




Generated by 
the Order 
Filler 

>Scheduled 

Protocol Code 
Sequence 

(0040,0008) 

0 

1C 





»Code Value 

(0008,0100) 

0 

1C 




Generated 
by the Order 
Filler 

»Coding Scheme 
Designator 

(0008,0102) 

0 

1C 




Generated by 
the Order 
Filler 

»Code Meaning 

(0008,0104) 

0 

3 




Generated by 
the Order 
Filler 

>Pre-Medication 

(0040,0012) 

0 

2C 





>Scheduled 
Procedure Step ID 

(0040,0009) 

0 

1 

N/A 



Generated by 
the Order 
Filler 

>Requested 

Contrast Agent 

(0032,1070) 

0 

2C 

N/A 



Generated by 
the Order 
Filler 

>Scheduled 
Procedure Step 

Status 

(0040,0020) 

0 

3 

N/A 



Generated by 
the Order 
Filler 

>A11 other 

Attributes from the 
Scheduled 

Procedure Step 
Module 


0 

3 





Scheduled Specimen Sequence 

Requested Procedure 

Requested 

Procedure ID 

(0040,1001) 

0 

1 




Generated by 
the Order 
Filler 

Requested 

Procedure 

Description 

(0032,1060) 

0 

1C 




Generated by 
the Order 
Filler. See 
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note 1 

Requested 

Procedure Code 
Sequence 

(0032,1064) 

0 

1C 





>Code Value 

(0008,0100) 

0 

1C 




Generated by 
the Order 
Filler. See 
note 1 

>Coding Scheme 
Designator 

(0008,0102) 

0 

1C 




Generated by 
the Order 
Filler. See 
note 1 

>Code Meaning 

(0008,0104) 

0 

3 




Generated by 
the Order 
Filler. See 
note 1 

Study Instance UID 

(0020.000D) 

0 

1 




Generated by 
the Order 
Filler 

Referenced Study 
Sequence 

(0008,1110) 

0 

2 





>Referenced SOP 
Class UID 

(0008,1150) 

0 

1C 





>Referenced SOP 
Instance UID 

(0008,1155) 

0 

1C 





Requested 

Procedure Priority 

(0040,1003) 

0 

2 

Quantity/ 

Timing 

00221.6 

OML 

ORC:7 

See note 2 

Patient Transport 
Arrangements 

(0040,1004) 

0 

2 

Transport 

Arrangem 

ent 

Response. 

01031.1 

-3 

OML 

OBR:30 


All other Attributes 
from the Requested 
Procedure Module 


0 

3 





Imaging Service Request 

Accession Number 

(0008,0050) 

0 

2 




Generated by 
the Order 
Filler 

Requesting 

Physician 

(0032,1032) 

0 

2 

Ordering 

Provider 

00226.1 

-7 

OML 

OBR:16 


Referring 

Physician's Name 

(0008,0090) 

0 

2 

Referring 

Doctor 

00138.1 

-7 

OML 

PV1:8 


Placer Issuer and 
Number 

(0040,2016) 

0 

2 

Placer 
Order # 

00216.1 

-2 

OML 

ORC:2 

See note 4 
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Filler Issuer and 
Number 

(0040,2017) 

0 

2 

Filler 

Order # 

00217.1 

-2 

OML 

ORC:3 

See note 4 

Reason for Imaging 
Service Request 

(0040,2001) 

0 

2 

Reason 
for Study 

00263 

OML 

OBR:31 


Entered by.... 

(0040,2008) 

0 

3 

Entered 

by.... 

00224.2 

-6 

OML 

ORC:10 


Order Entering 
Location 

(0040,2009) 

0 

3 

Entering 

Organizati 

on 

00231.2 

OML 

ORC:17 


Order Callback 
Phone Number 

(0040,2010) 

0 

3 

Order 

Callback 

Phone 

Number 

00228 

OML 

ORC:14 


All other Attributes 
from the Scheduled 
Procedure Step 
Module 


0 

3 





Visit Identification 

Admission ID 

(0038,0010) 

0 

2 

Patient 
Account 
Number 
or Visit 
Number 

00121.1 

or 

00149.1 

OML 

PID: 18 

or 

PV1:19 

See note 6 

Issuer of Admission 

ID 

(0038,0011) 

0 

2 

Patient 
Account 
Number 
or Visit 
Number 

00121.4 

or 

00149.4 

OML 

PID: 18 
or P V1 - 
19 

See note 6 

All other Attributes 
from the Visit 
Identification 

Module 


0 

3 





Visit Status 

Current Patient 
Location 

(0038,0300) 

0 

2 

Assigned 
Pat. Loc. 

00133 

OML 

PV1:3 


All other Attributes 
from the Visit 

Status Module 


0 

3 





Visit Relationship 

Referenced Patient 
Sequence 

(0008,1120) 

0 

2 





>Referenced SOP 
Class UID 

(0008,1150) 

0 

2 





>Referenced SOP 
Instance UID 

(0008,1155) 

0 

2 
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All other Attributes 
from the Visit 
Relationship 

Module 


0 

3 





Visit Admission 

All Attributes from 
the Visit Admission 
Module 


0 

3 





Patient Relationship 

All Attributes from 
the Patient 
Relationship 

Module 


0 

3 





Patient Identification 

Patient's Name 

(0010,0010) 

R 

1 

Patient 

Name 

00108 

OML 

PID:5 

See note 10 

Patient ID 

(0010,0020) 

R 

1 

External 
Patient ID 

00105.1 

OML 

PID:2 

See note 5 

Issuer of Patient ID 

(0010,0021) 

O 

3 

External 
Patient ID 

00105.4 

OML 

PID:2 

See note 5 

Ethnic Group 

(0010,2160) 

O 

3 

Ethnic 

Group 

00125 

OML 

PID:22 


All other Attributes 
from the Patient 
Identification 

Module 


O 

3 





Patient Demographic 

Patients Birth Date 

(0010,0030) 

O 

2 

Date/ 

Time of 
Birth 

00110.1 

OML 

PID:7 


Patient's Sex 

(0010,0040) 

O 

2 

Sex 

00111 

OML 

PID:8 

See Note 11 

Patient's Weight 

(0010,1030) 

O 

2 

Observati 
on Value 

00573 

when 

00571.2 

="Body 

Weight" 

and 

00574.1 
= "kg" 

ADT 

OBX:5 

See note 7 

Patient's Size 

(0010,1020) 

O 

2 

Observati 
on Value 

00573 
when 
00571.2 
="Body 
Height" 

ADT 

OBX:5 

See note 7 
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and 

00574.1 
= "m" 



Confidentiality 
constraint on 
patient data 

(0040,3001) 

0 

2 

VIP 

Indicator 

146 

OML 

PV1:16 


Region of 

Residence 

(0010,2152) 

0 

3 

Citizenshi 

P 

00129 

OML 

PID:26 


Military Rank 

(0010,1080) 

0 

3 

Veterans 

Military 

Status 

00130 

OML 

PID:27 


All other Attributes 
from the Patient 
Demographic 

Module 


0 

3 





Patient Medical 

Patient State 

(0038,0500) 

0 

2 

Danger 

Code 

00246 

OML 

OBR:12 


Pregnancy Status 

(0010,2 ICO) 

0 

2 

Ambulato 
ry Status 

00145 

OML 

P V 1:15 

"B6" must be 

mapped to 

DICOM 

enumerated 

value "3" 

(definitely 

pregnant). 

Medical Alerts 

(0010,2000) 

0 

2 

Relevant 

Clinical 

Info 

00247 

OML 

OBR:13 


Contrast Allergies 

(0010,2110) 

0 

2 

Allergy 

Code 

00205 

ADT 

AL1:3 


Special Needs 

(0038,0050) 

0 

2 





All other Attributes 
from the Patient 
Medical Module 


0 

3 






Adapted from DICOM PS 3.4 

Note 1: Universal Service ID and Specimen Source decoding: 

In order to fulfill an accepted order, the Order Filler generates one or more 
Requested procedures, to which it assigns IDs and proper codes, taken from 
1865 either local or universal coding scheme (such as CPT-4 or LOINC)". 

If laterality is not specified in the Universal Service ID then it is recommended 
to use Specimen Source (00249) to further clarify the free format text 
descriptions of the Order. 

Note 2: Only the suggested values of the HL7 Priority component of Quantity/Timing shall 
1870 be used for IHE. These values shall be mapped to the DICOM enumerated fields for Priority 
as: 
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HL7 Status 

DICOM Status 

S - STAT 

STAT 

A - ASAP 

HIGH 

R - Routine 

ROUTINE 

P - Pre-op 

HIGH 

C - Callback 

HIGH 

T - Timing 

MEDIUM 


Note 3: Order Filler/Order Filler shall determine the value of DICOM Modality (0008,0060) 
1875 attribute based on the content of the order. The DICOM defined terms must be used for the 
MWL response as listed in DICOM PS 3.3. 

Note 4: Attributes (0040,2016) and (0040, 2017) are designed to incorporate the HL7 
components of Placer Issuer and Number, and Filler Issuer and Number. In a healthcare 
enterprise with multiple issuers of patient identifiers, both the issuer name and number are 
1880 required to guarantee uniqueness. 

Note 5: As discussed in sec. 4.1.4.1.2.4, either field PID-18 Patient Account Number or field 
PV1-19 Visit Number or both may be valued depending on the specific national requirements. 
Whenever field PV1-19 Visit Number in an order message is valued, its components shall be 
used to populate Admission ID (0038,0010) and Issuer of Admission ID (0038,0011) 
1885 attributes in the MWL responses. In the case where field PV1-19 Visit Number is not valued, 
these attributes shall be valued from components of field PID-18 Patient Account Number. 
This requires that Visit Numbers be unique across all account numbers. 

Note 6: Patient's Weight and Patient's Size are two observations from multiple OBX 
segments. A coding scheme is not specified by IHE, but rather, the text values of "Body 
1890 Weight" and "Body Height", respectively, are required to differentiate the two measurements. 
Note that DICOM specifies the use of "kg" and "m", respectively, for these measurements. 
An example of this HL7 encoding is: 

OBXIISTDBODY WEIGHTII62lkglllllF 
OBXIISTDBODY HEIGHTII1.90lmlllllF 

1895 Note 7: The DICOM attribute (0038, 0050) Special Needs is listed in table D-l with no 
specific mapping from an HL7 message. In the IHE demonstration, this value is to be 
provided by the DS S/Order Filler. The prospect of mapping this attribute to an HL7 value 
will be examined in the future. 

Note 8: Field OBR-34 Technician in OML message is repeatable. Its data type is CM, with 
1900 the following components: cname (CN)> A <start date/time (TS)> A <end date/time (TS)> A 
<point of care (IS)> A croom (IS)> A <bed (IS)> A <facility (HD)> A docation status (IS)> A 
<patient location type (IS)> A cbuilding (IS)> A <floor (IS)> 

Thus, in mapping value to the DICOM attribute Scheduled Performing Physician 
(0040,0006), only sub-components of the first component of the first repetition of 
1905 that field shall be used. 

Note 9: The encoding of the patient’s name in the HL7 OML PID:5 components is mapped 
without changes into the DICOM components in the Patient’s Name (0010,0010) attribute as 
follows: 

HL7 DICOM 
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1910 


1915 


1920 


1925 


<family_name&last_name_prefix> => 


<given_name> => 

<middle_initial_or_name> => 

<suffixxdegree> => 

<prefix> => 


<family_name_complex> 

<given_name_complex> 

<middle_name> 

<name_suffix> 

<name_prefix> 


The HL7 “degree” component is absorbed as a second element in the “name_suffix” 
component in DICOM. 

Note 10: The DICOM Patient’s Sex (0010,0040) attribute can have only the values M, F or O 
(for other), or be zero length if unknown. These are enumerated values and hence any other 
values would be illegal. The HL7 V2.5 description also uses M, F and O, but suggests a value 
of U for unknown, which needs to be mapped to zero length. In HL7 these are only suggested 
values however, and care should be taken to map any other values encountered to valid 
DICOM values. Note also that in HL7 V2.5.1, the additional suggested values of A meaning 
Ambiguous and N meaning Not applicable, are present, and again, these would be illegal in 
DICOM and need to be mapped to O. 
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